Re: Lua library bank? (Was: Ruby philosophy vs Lua philosophy

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

On Sat, Mar 9, 2013 at 7:11 PM, Andrew Starks <andrew.starks@trms.com> wrote:
> Make something like luadocs responsible for building documentation and
> launching viewers. It must be used for all packages in luarocks.

What this does mean is that there is an extra bunch of obligatory
requirements a package must meet. Personally, I'm a fan of luadoc-like
markup but if the package author has written nice documentation
without that, then that will suffice. Rockspecs always have an
associated URL and that should point to a useful website.

> Developers can use whatever source control is appropriate. If they
> want to submit to luarocks, it must be in a git repository. We create
> a template where all of the directories are in place, with
> instructions on how things should work.

I don't think Hisham would want to insist on that, since he wants the
repo open to all who go to the trouble of packaging projects; a
rockspec has quite explicit instructions on how the contents are
structured, whether the contents come from a traditional archive or
from a git/svn reference. (So yes, LR _does_ use git; if it used
lua-git then the user would not even need Git installed.)

> In luarocks, we standardize on a build tool that is delivered with
> luarocks. It is always used, without exceptions.

Follow that idea and we have LuaDist, which was designed to make
building the Lua ecosystem as platform/toolchain independent as
possible; that meant CMake.  Remember that luarocks does have a
built-in build tool, which is sufficient to build many Lua C packages
(even somewhat complicated ones like LuaSocket); but what tends to
happen is that there is an existing makefile, which works on their
machines, and then they package that.  (There is a useful distinction
between 'development' build systems and 'deployment' build systems
hanging around here.)

> Work towards the goal of a CI server that tests every tree package on
> a handful of platforms.

Well, everyone organizes tests differently, and uses a fair number of
independent testing libraries (like build tools, everyone seems to get
an itch to write testing tools).  One could imagine an extension of
the rockspec format where the packager could specify how to to _test_
the package, including test dependencies.

> The package consumer's experience is most important, I believe.

There we must all agree.  But if there are too many hoops that the
package producer must jump through, then not everyone wants to go
through the trouble; it feels like bureaucratic overhead.  Although
it's true that the _package author_ and the _package maintainer_ are
quite distinct concepts.  In any future revision of the rockspec
format, it must be possible to express that distinction.   That makes
it easier for a gang of dedicated packagers to let the project
developers do their own sweet, indispensable thing.  That's how
LuaDist has managed to cover so many projects, and is certainly how
something like Debian works.

steve d.