[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua Distributions and Package Management
- From: Philipp Janda <siffiejoe@...>
- Date: Sun, 29 Sep 2013 18:11:40 +0200
Am 29.09.2013 14:06 schröbte steve donovan:
On Sun, Sep 29, 2013 at 12:17 PM, John Hind <firstname.lastname@example.org> wrote:
Installation is a one-off procedure and it is more important that it is
reliable and automated than that it is as fast as possible. I'd rather spend
10 minutes staring at a progress bar than half a day trying to debug a
That's a good point. The LuaRocks built-in backend works like how you
describe; it directly invokes the configured compiler to build
extensions. (People have LR working quite fine with MSVC). The
problem is that people usually have a makefile, and so the easiest
route to publishing as a LR rock is to use that makefile. It's
possible to do reasonably complex builds with the built-in backend,
for instance I once got LuaSocket building like that cross-platform,
but that's an extra bit of effort.
And that's why I don't get what this discussion is about: Luarocks
offers a nice, simple, cross-platform description of how a package is
built, and still lets the developer choose his/her build tool of choice
(or none at all with the `builtin` build type, which is very convenient
for the user).
Some modules require luarocks to build, so what? The situation is hardly
different with other scripting languages: E.g. there's
`ExtUtils::MakeMaker` and `Makefile.PL` for Perl, and `Distutils` and
`setup.py` for Python. Plus a lot of packages already provide rockspecs.
I can understand that some people don't want to install the resulting
files in the rocks tree, but that can be achieved simply with a new
luarocks subcommand (something like `luarocks make` which doesn't
check/download dependencies and moves the resulting files into a
subdirectory of the source directory[*] instead of installing into the
Maybe we could also provide a standalone script (or module) that is
easier to install than luarocks (maybe some amalgamation of the
necessary luarocks source files packaged as a single standalone
module/script), but that's as far as I would go.
So our efforts should be directed at making luarocks better instead of
creating yet another build tool ...
Everything IMHO, of course.
[*]: My suggestion would be `lua_path` and `lua_cpath` (and `lua_bin`
for scripts). Then the installation instructions for a manual install
luarocks manual[**] some.rockspec
mv lua_path/* some-dir-in-LUA_PATH/
mv lua_cpath/* some-dir-in-LUA_CPATH/
mv lua_bin/* some-dir-in-your-PATH
[**]: Subcommand name still subject to change ;-)