LuaRocks new chance (was: lgi 0.2 - Lua to GObject (GNOME) libraries binding)

[Javier Guerra Giraldez <javier@...>]

On Thu, Nov 24, 2011 at 10:55 AM, Hisham <hisham.hm@gmail.com> wrote:
> On Thu, Nov 24, 2011 at 12:42 PM, Javier Guerra Giraldez
> <javier@guerrag.com> wrote:
>> i've tried that a few times, but what i get is a non-standard tree and
>> a preloader. it was a few months ago, so i don't remember the
>> details;
>
> Well, it was certainly many months ago! LuaRocks supports standard
> trees without preloaders since October 2009.

no, it definitely was 2011.  in fact, i tried it precisely because i
remembered some (old) comments here said that.

>> but could that be because
>>
>> - how luarocks itself was installed / configured?
>
> The default setup installs to standard tree under /usr/local. To
> install to a user-specific ~/.luarocks tree you can use the --local
> flag (this switching used to be automatic according to permissions,
> but since December 2010 it's explicit: if it runs without permissions
> to install in the system tree, it fails and you have to pass --local).

is there some FAQ about this?  one that doesn't assume i already know
the luarocks way, but specifically for "don't mess with my system"
people?


> On Windows there is no "standard path", so it depends on how install
> it, but AFAIK Lua for Windows ships a copy of LuaRocks that's
> configured to point to appropriate paths.

fair enough.  (i guess, but don't really care about windows tools;
when i have to ship a windows-friendly package, i include all
dependencies... hum, another reason to get a readable description of
dependencies)


>> - how it was invoked?
>>
>> - something about the specific packages i was installing?
>
> Hard to tell, but one of the goals of LuaRocks is to make installation
> of packages consistent. External dependencies are sometimes tricky due
> to differences in distros, but we try to be as generic as possible.
>
>> also, how can i tell luarocks that i already have something installed,
>> not from a rock but as a standard module?
>
> I can add that to the wishlist: I could add a feature to allow you to
> tell LuaRocks that a given version of a given rock doesn't need to be
> fetched as a dependency (and it would be up to the user to ensure the
> version is properly installed and compatible), but that's as far as
> one could go.
> Would that be desirable?
>
> Detecting what is installed in the system is impossible, due to the
> lack of standardized versioning in modules.

if it shows the dependencies, i can just ignore what i already have.
or maybe a "don't care about versions, if it's require()able, it's
fine" mode.


>> maybe just a rockspec->english (or bash, or whatever) translator would
>> be better for old stubborn guys like me....
>
> Well, if I were to write a rockspec->bash script to run the rockspec,
> I might as well write a rockspec->Lua script to run the rockspec... oh
> wait, that would be LuaRocks. :o)

yeah, as long as it has a dry-run option, to let me see what is it
trying to do and do it myself, and if it's readable without having to
care about inner works of LuaRocks.

but what i'd really want is: from a rockspeck, print the dependency
tree (maybe pruned if i can register the 'already have' packages), and
the 'what goes where' of the specific package.




-- 
Javier