Re: Upstream is not the last word (was Re: [ANN] Lua 5.1.5 (rc1) now available)

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

On Mon, Feb 13, 2012 at 8:22 PM, Jay Carlson <nop@nop.com> wrote:
> We're far better off than in the past. luarocks can handle the "everything" part and let people pick and choose;

I mostly agree, although there's a fair amount of work to make LR
really sing on Windows.  And it annoys Linux people because it does
not recognize the native package manager - there's a _lot_ of good
basic Lua functionality in the Debian repositories. If a package needs
lfs then LR will pull in lfs and not see liblua5.1-filesystem0 as
satisfying that need. (This is _not_ an easy problem to solve, because
of the versioning issues, especially hard to frame as a cross-platform
solution.)

But LR isn't an obvious way to deliver stuff to an embedder.

> I want to cut features ruthlessly until we mostly agree we all use something from time to time, and it looks and acts mostly the same--or there's an obvious winner for correctness/efficiency/simplicity.

That's an admirable approach, much admired by Roberto and lhf.  In
practice, it's very hard to get us to agree on _anything_. I remember
a discussion about the signature for a map() function; no agreement
was possible on _one_ such function because there's actually a family
of such functions,  table -> table, iterator -> iterator, etc.

> If luarocks really wants to help, add an implicit dependency on a base package to everything;

Ah, but it's a no-brainer for a rock author to add a base dependency;
the question is what will that be?  Call it 'baselib' and get ruthless
with it, a hundred well-curated utility functions, maybe 2KLoc.  It's
understood that it will be a disappointment to many, that's cool.  (I
could make something like that by tomorrow by taking a sharp knife to
Penlight, but that's the easy part.)

A promising approach is to define luarocks meta-packages  - e.g. we
can call one 'lua-batteries' and it will be a package that simply
pulls in a set of commonly-useful stuff packages.  That's a reasonable
way to do a cross-platform Lua distribution.

The intention remains to use LuaDist as the sane cross-platform
package builder and LuaRocks as the distribution channel.  However, we
keep getting distracted ;)

While it's ramble-week on lua-l, I'd like to return to the 'static
linking' meme.  You can give a short but powerful Python script to
your chums because they have the platform. Making that into an
executable for the world is a painful exercise.  Now with something
like Squish, you can write a short but powerful Lua script, 'compile'
it into a self-contained script and glue that script to a Lua
executable using srlua.  The result is going to be in the region of
200K, (depending on what Lua binary extensions need to be statically
linked in) and that's practically small change by modern standards.
Combine this strategy with LR and you _do_ have a way for an embedder
to use existing batteries without (for instance) pulling in the whole
10Kloc of penlight.

steve d.