Re: [ANN] LuaRocks 2.0.13

[steve donovan <steve.j.donovan@...>]

On Wed, Apr 17, 2013 at 11:42 AM, Rob Kendrick <rjek@rjek.com> wrote:

I've always thought it might be nice if the way luarocks operated on
systems with package managers is to use that package manager.  ie, if
you install a rock, this involves converting it to a native package and
installing it.

It's doable, but does involve some legwork. E.g. start out with 'fake' rockspecs defining the exact _version_ of the several dozen Lua packages available in Debian, and if a user has already got luasocket from apt-get, then regard that as satisfying a dependency. The Problem happens when the user wishes to move to a new shiny luasocket, and that's when we have to speak the package manager's language.

deb-packaging isn't too difficult, but it's a big extra thing for a tool that has to stretch across so many platforms.  Someone might set up an Ubuntu PPA for tracking updates to Lua packages  (since Enrico Tassi must work in the slow but sure Debian release cycle), ditto for equivalent RPM mechanisms and so forth.

The current situation is that the typical LR user must be prepared to _build_ some fairly hairy stuff, which is exactly why the package managers are such fantastically helpful environments - compatible binaries.

We have a similar situation with the proposed Lua for Windows/whatever reboot; there is a LuaRocks version available with Peter D's batteries, but it works independently (and doesn't end up on your usual module path) There the problem is easier because one can build a fake LR manifest from the known packages in the batteries.

A LD Batteries for Linux is part of the plan, and then the problem is further compounded ;)