Re: RES: package system modification (module loaders)

[Mike Pall <mikelu-0501@...>]

Hi,

Andre de Leiradella wrote:
> I didn't look at the package system proposal [...]
> [...] because the code to do it would still be there [...]

Everything related to packages is inside one source file and it's pretty
easy not to link it in. It does help to do a bit of research sometimes. ;-)

> I'm not against a package system for Lua, but I think that it should be
> an add-on to Lua, completely separate from the core.

You can see the result of this thinking when you look at the add-on modules
available for Lua. Sure, _you_ don't need any of these. But I and many
others want to reuse other peoples modules without having to think about
a dozen different ways to integrate and load them. Right now this is a real
mess (have a look at the Wiki, download a dozen modules and start to worry).

Really, the package proposal is a call for standardization in an area of
central importance for Lua. The proposal is so important because the
Lua core is so small (intentionally). This means that you absolutely need
to use add-on modules to do anything interesting. That's why it should be
dead easy to write, to integrate and to use add-on modules in a standard way.

There is still some way to go until we can do the equivalent of 'cpan foo'
to install a module. In the meanwhile I can settle for manual download,
unpack and make install. At least for the standard dynamic linking case this
should be all I need to do.

Even if you want to staticall link your modules, it _does_ help when all
module init functions obey to a common naming standard and behave the same
way. And it really helps if there is a single standard way to use a module,
too (local foo = require "foo"). This means you can switch from dynamic
linking to static linking without changing all of your Lua modules.


I won't settle for less -- it's just so much more productive to be able
to say 'apt-get foo' or 'emerge foo' or whatever the equivalent of it is
on your OS packaging system. Without this I would still sit there and try
to figure out how to get X up and running from the original MIT X11 source
and two dozen incompatible patches from around the world. I did so, more
than a decade ago. Believe me it was no fun, I don't want this time back.

This is largely due to the efforts in the open source community to
standardize on a way to deliver your code (autoconf + pkg-config + automake +
make + tar + gz) and on behalf of the distribution maintainers standardizing
on a package system that automates the download, build and installation
process (please do not start a discussion about the relative merits of
any of these tools here on this list -- none of them is optimal, but you
have to admit they do their job).

It's all about saving time and being able to reuse the work of others.
Everyone will benefit.

Bye,
     Mike