lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]



> On Apr 12, 2019, at 6:50 AM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> 
> The Lua ecosystem will never be worth that name as long as there is no
> way to address the module naming issue.
> 
> There are two modules available via LuaRocks, neither of which is
> called `complex` but both of which install a module loadable (in
> theory) by
> `require "complex"`. I have been using one for years, the other (where
> `complex` is only incidental support for a main module) only for a
> week. When today I ran a program dependent on the first of these
> modules, it failed, because the interface for the two modules is
> different, and the second module, finding its code in a file called
> complex.lua, is preferred over the first, which finds its code in a
> file called complex.so.
> 
> Of course there are workarounds. I know them.
> 
> But life could be made easier for the poor programmer by addressing
> two great defects:
> 
> In the Lua standard library, there is no easy way of detecting where
> the module was found. One can repeat all the work using
> package.searchpath to find out where the module should have been
> found, but you can't check whether the module actually loaded was that
> one.
> 
> In LuaRocks, there is no check, when you install a rock, that there
> could be naming conflicts between modules supplied by that rock and
> modules supllied by rocks already loaded.
> 
> One is really forced to check for signatures in installed modules, or
> run a functionality check, or supply such a detailed package.path that
> the desired module can't be missed. Any of these makes a mockery of
> the supposed ease of use of the module system.
> 


+1 .. imho this is one of the weaker aspects of Lua. While I realize Lua is primarily an embedded language (and I use it as such), I think this model carries over too much (perhaps unconsciously) into the module system, which only really works if (a) you have written the script yourself and (b) you control ALL the module installs. This is of course fine if you are embedding, but basically means creating a general-purpose Lua script for use by others is fraught with difficulties.

As for suggestions .. I’m sure many people here know the various design patterns, but in Lua-land it all really comes down to two issues:

1. A unified identity system for modules (note I said identity, not name). This can’t depend on balkanized issues such as paths either.
2. A recommended pattern for using a module within code that handles mapping module identities to bound names.

I realize Robero et al feel that Lua should be as policy-free as possible, but I think Lua and the community would really benefit from some guidance here.

—Tim