[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: lua libraries
- From: kevin beckford <chiggsy@...>
- Date: Sun, 16 Jan 2011 18:49:21 -0800
On Sun, Jan 16, 2011 at 2:03 AM, steve donovan
> On Sun, Jan 16, 2011 at 11:31 AM, kevin beckford <firstname.lastname@example.org> wrote:
>> "Wait, why can't I just bind lua to the getopt library?"
> Good question, except for the 'just'. In fact it might be easier to
> carefully study the specs and write a compatible library in Lua.
Thanks for all the advice, I think that's the way I will proceed.
> As for preferring to use the system package manager, it seems to be a
> good way to go, (unless you don't have a package manager. Windows
> package management seems to be a fragmented, fringe activity.)
Well, in general, I use whatever the system pkg manager is to install
stuff that I am not developing in, and the applications languages
manager for the things that I am coding myself. I expect variance in
that , and am testing for it. Not so much for base libraries.
> However, one cannot expect the package manager to keep up-to-date with
> bleeding-edge releases or small specialized libraries, which is where
> luarocks is useful. But I've noticed there's a certain tension in the
> air between LR and apt-get, since LR e.g will not recognize the Debian
> LuaSockets package as satisfying any such dependency in LR packages.
The FHS may have it's flaws, but if everybody installed to
/opt/langname/version/blablaba, then all the drama would seem to be
over *shrugs*. I'll admit, /opt/local/$lang does not have the cachet
of the usr tree, but...