Even worse!

Lets look at the Orbit web framework. This framework was (and likely still is) broken because a dependency to a pattern matching library that changed. The patch is only a few lines, but a door stopper for anybody who tried Lua for the web.

Now lets look at a simpler problem. Your script wants to change directory, but Lua is lacking a chdir function. Google will tell you, that this is in some POSIX library, and Debian or your distribution of choice of course offers a POSIX package for its Lua. Soon you start to wonder: Is there any documentation, what else is implemented in this posix lib? You find no docu, instead you find dozens of Lua posix packages, all without documentation and all without regression tests all over the web. Wondering, what did the maintainer of your distribution of choice pick?

Praise the Lord! The church saw that module system was bad, and decided to remove the module keyword from the language with Lua 5.2 to get rid of all those bad modules :D

imho, there is a cultural difference. There is more then one way to do it in Perl, exactly one way to do it in Python, but in Lua you have to DIY.

Lua has two strongholds, where it excels: Education, where its nice, that the teacher has an excuse to dig deep into C bindings, just to implement a chdir function. And in systems where Lua acts as a glue language. A module system would be counterproductive in both cases.

zserge> Anybody?

I'm hanging around in #lua on irc.freenode.net for a chat.

Speaker here, funny this got picked up by HN over a year after my talk.

Why makes you think LuaRocks is not the best package manager for Lua? As far as I can tell, it is.

Things have changed since last year, too! My suggestion of slide 40 ("programmatic releases for LuaRocks") has been implemented by merging with MoonRocks, which is now the official source for packages.

This has accelerated the rate of packaging: as of today there are over 500 packages available.

That being said, if you want to make things better there sure are lot of things that could be done. If you want to contribute the best place to reach the community is probably the lua-l mailing list and the more specific luarocks-developers mailing list.

Oh, thanks for a prompt response! I personally got stuck with LuaRocks and cross-compilation for our MIPS board. Probably it was lack of documentation or lack of my knowledge. So instead I manually crafted most of the packages we needed either from scratch or by writing custom makefiles for existing ones (that was more than a year ago).

The whole idea of rockspec looks very nice to me and I totally support it.

But can I keep a global aka system rocktree and a per-project local trees? (Pardon my ignorance, I really don't know that). Per-project trees make deployment a lot easier.

Also, why can't "luarocks" or "moonrocks" be a single executable/script? Isn't it easier to get user just a download link instead of: "download it here, unpack, configure, make build, make install, now use it to install moonrocks"? (Also, I'm not saying that it's a very complex procedure, I know most people can do it easily, but that leaves an impression that the LuaRocks project is not very user-friendly).

Note: I am not the author of LuaRocks (https://news.ycombinator.com/user?id=hisham_hm is), just a user.

Regarding distribution, what OS are you talking about? LuaRocks is available in Homebrew for OS X and as a package in most Linux distributions. Windows build looks a bit more painful but I don't have experience with that OS.

Regarding per project trees, there is no such thing as what exists in Python with virtualenv, but you can certainly do this:

    $ mkdir my_project
    $ cd my_project
    $ mkdir rocks
    $ luarocks-5.2 --tree="./rocks" install haricot

This will install the latest version of Haricot and all its dependencies (in this case LuaSocket) in the local tree regardless of whether you have them system-wide. Note that you can change this behavior (http://luarocks.org/en/Dependencies) but the default dependency mode is "one".

LuaRocks dev here, thank you for the feedback!

> But can I keep a global aka system rocktree and a per-project local trees? (Pardon my ignorance, I really don't know that). Per-project trees make deployment a lot easier.

Yes, catwell's comment expanded on it below.

> Also, why can't "luarocks" or "moonrocks" be a single executable/script?

The documentation on the website is outdated. Nowadays the "luarocks" command has absorbed the functionality of the "moonrocks" script. Just use "luarocks upload foo-1.0-1.rockspec".