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

[Andrew Starks <andrew.starks@...>]

On Sat, Mar 9, 2013 at 1:00 AM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> Why another package searcher? Can't we simply use kpse? Remember, Lua
> is part of TeX now. There are over 600 Lua source files in texlive2012.
>
> I've made a little experiment: created a "lua" subdirectory in
> my $HOME/texmf/tex, put some modules in there, ran texhash.
> `kpsewhich` finds the .lua files but not the .so files. So there is
> clearly already something special about the .lua extension, even
> though there is no specialized file type 'lua'.
>

By package searcher, I was talking about a thin onion layer on top of
the built-in lua one. One which, you could say `rocktree =
{"/usr/local/share/lua/rocks", "~/src/rocks", "etc..."}` and the
searcher would append `package.path` and `package.cpath` to look where
it needed to look.  This is where a MikTeX like "autoloader"  would
go. `require` stays the same. In fact, the Lua 5.2 Reference Manual
and PiL both say that this is where additional package searchers are
to be put, so it's really not monkey patching, imho.

I have not given due credit to luarocks and I owe an 'internal'
apology to those that have been doing great work with it, especially
Hisham. (internal because I haven't cursed anyone publicly :). Pretty
close to everything I was looking for is being done already and the
things that *I* see as limitations are due to cultural and resource
considerations.

I believe that Lua's culture of "mechanisms, not policy" applies here,
but at an adjusted level. Everything is already provided to create a
nice little world inside of luarocks, which can be used to further
automate module installation and bundled build deployments. The rest
of Lua can work equally well, six ways from sunday.

So, if I can shorten and revise my earlier email to observe some
possible areas of adjustment:

Make luarocks local trees like TEXMF trees in that they are the single
point where everything for all modules is found. If an external
requirement isn't found, the normal lua environment is searched.

Make something like luadocs responsible for building documentation and
launching viewers. It must be used for all packages in luarocks.

Keep the git repositories there by default and link to executables
from their "build" directory. This will simplify branching, patching,
etc.

Allow the build directory to include binaries for specific platforms,
if the author can do so. This is important for windows. Use branching
to keep options for lightweight downloads.

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.

In luarocks, we standardize on a build tool that is delivered with
luarocks. It is always used, without exceptions. Because they have the
git repository, alternates can be there. It just *must work* with the
build tool that is part of luarocks.

Have luarocks use git's downloading facilities.

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


Here's the deal: Imagine that there is a nice ecosystem of a handful
of important packages (perhaps Steve's LuaBuild project) that are
ported into a structure like this. We make a nice user experience for
people and they're able to read documentation, swap module
environments, patch and merge updates, and things work smoothly in all
major platforms, then package writers will want to automate their
process of making modules that they write port into this system.
They'll want to be a part of it because people think it's important
and they want their stuff used.

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

-Andrew