[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Google Summer of Code 2013
- From: Sean Conner <sean@...>
- Date: Tue, 26 Feb 2013 12:07:03 -0500
It was thus said that the Great Peter Drahoš once stated:
> On 25 Feb, 2013, at 23:45 , Eric Wing <email@example.com> wrote:
> > Google Summer of Code 2013 was announced on the 14th. Every year, we
> > seem to bring this up at the last minute, so here's my attempt to kick
> > off the discussion a bit earlier :)
> > So how about it?
> What Lua really needs in my opinion is a standardized package structure
> similar to CPAN. Currently we have two automated distribution tools
> LuaDist and LuaRocks that are reasonably similar with some
> philosophical differences. The deployment and building of modules is more
> or less solved (LuaRocks builds using various methods, LuaDist uses
> CMake). However the following issues are still present:
I personally prefer LuaRocks over LuaDist (I've never heard of LuaDist) if
for one reason---LuaRocks does not require CMake (none of the systems I use
have CMake installed) and in fact, can use the existing build system of the
> - Package names should reflect the modules installed by it
For LuaRocks, all that's required is changing the name of the rockspecs
and making sure the package field reflects the name. So that's not really a
technical issue .
> - No documentation standard
> Yes, we have multiple generators and some packages even generate nice
> documentation but most packages simply do not have any documentation.
> Additionally the documentation should be accessible from the interpreter
> itself so IDEs can access it directly. For example require
> "doc.luafilesystem" would return documentation associated with the module
> (in some standardized form). Or require "api.luafilesystem" would contain
> a structure useful for autocomplete systems in IDEs etc.
This is definitely a social issue. It's a good idea (and LuaRocks has
bitched at me constantly for lacking a doc/ directory) but you need to
pressure developers to write good documentation (and I'm guilty of less than
> - No testing standard
Another social issue, not a technical one.
 I've been playing around with LuaRocks over the weekend, and I've
been able to make a rockspec that handles installing
Even more nice---all you need is the rockspec to install it.
 I just did a test where I named the rockspec to reflect the module
name, and it worked just fine.