Re: [ANN] Lua for Linux, alpha release

[Hisham <hisham.hm@...>]

On Thu, Jun 18, 2009 at 9:07 AM, RJP Computing<rjpcomputing@gmail.com> wrote:
>
>
> On Thu, Jun 18, 2009 at 7:20 AM, David Given <dg@cowlark.com> wrote:
>>
>> Miles Bader wrote:
>> [...]
>>>
>>> The main drawback is that not every package is available, and you have
>>> to <do something else> for those that aren't.  Maybe run luarocks, but
>>> native debian packages probably have a big advantage for packages which
>>> require non-Lua components.
>>
>> The obvious thing to do here is to enhance LuaRocks so that it'll generate
>> compliant Debian, Red Hat etc packages. That way LuaRocks simply becomes
>> Debian and Red Hat's official source for the packages, which means they all
>> get built automatically and end up in the archives.
>>
>> It's probably worth mentioning that as a Debian and Ubuntu user, I don't
>> *want* to use LuaRocks, for exactly the same reason that I don't use CPAN or
>> RubyGems etc. It's too much hassle. Not LuaRocks itself, but managing the
>> composite system of some Debian packages and some manually installed
>> packages is simply more trouble than it's worth. On the rare occasions I'm
>> working on a project which needs a library that's not in Debian I'll usually
>> just copy the source for the library into my project. It's just easier that
>> way, and it's certainly easier on my users...
>>
>> (Not that I'm denigrating the work that's gone into LuaRocks. It's a great
>> thing to have. It's just I'm not in LuaRocks' audience, because I live in a
>> different ecosystem than LuaRocks was designed for.)
>
> I don't think I could say it any better. These are my exact thoughts.

You may not want to use LuaRocks, but LuaRocks still wants to be
useful for you. :)

While LuaRocks functions as a Lua-specific package manager, it can
also be seen as a Lua-oriented build tool. So you may only use
apt-get, but the Debian maintainer may use LuaRocks to build .debs.

That is especially interesting in the light of the work that's going
into LuaRocks 2.0, which will provide a modules tree that's compatible
with vanilla Lua. It's even conceivable that the process of making
rocks-to-debs, rocks-to-rpms, etc, can be largely automated (if not
completely, due to external dependencies).

For distro maintainers, this would allow them to factor out common
work into the rock (possibly with with upstream collaboration). For
users, using LuaRocks through their own package manager brings a more
consistent interface and better external dependency tracking.

I expect to have at least a beta for LuaRocks 2.0 later this month,
and I invite anyone who's interested in it, especially distro
maintainers, to come over at the luarocks-developers mailing list so
we can discuss the specifics.

-- Hisham