Re: Lua library bank?

[David Heiko Kolf <kolf@...>]

steve donovan wrote:
> An excellent idea, but we already have a lot of modules that grew
> organically, mostly in isolation.  My head is so used to luafilesystem
> and luasocket that it would hurt to have to move to something else,
> even if it were better engineered and better named. It's hard to tear
> up the floorboards if you don't have anywhere else to stay.
> 
> But I'm not sure what you're proposing; is it a _distribution_?  We
> already have these. Best candidate so far is the 'Lua for Batteries'
> binaries as listed on the front page of http://luadist.org/.

Relating to the question of why Lua isn't more widely used in situations
where nowadays Ruby, Python or PHP are used, the lack of a standard
library was mentioned.

If I were a hosting provider and wanted to provide Lua as an additional
language, what packages would I take?  Here LuaRocks would probably not
be available to the customer.  And the hosting provider probably does
not have the time and experience to hand select a dozen modules.  (And
to look for patches to make them work on the latest Lua version).

If I would write a web application, what dependencies could I use
without requiring the users to install additional binary packages on a
system they might not even have full access to?

The LuaDist batteries are probably quite close to that role.  Maybe it
would be enough to put this project prominently on lua-users.org and
point everyone in that direction for default modules.  lua.org already
points in its download section to Lua for Windows.  However the keywords
"for Windows" might be a problem.

I have to take a closer look at LuaDist myself as well.  Does it offer a
united build process where I could take the entire default distribution
and say "./configure && make" (or similar) and have all the modules
built at once?

I suggested a new namespace for modules in a standard package to
indicate that for those modules the original authors no longer take sole
responsibility but that they are considered as core modules where
multiple volunteers can update or even replace them in a central
repository and new versions of the entire library are discussed on this
list before fixing a release.  And I would not suggest to rewrite all
the common modules -- if the API looks good, there would be no reason to
reinvent wheel.

Best regards,

David Kolf