lua-users home
lua-l archive

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

On 12 Apr 2019, at 15:50, Dirk Laurie <> 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

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

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.

Hi Dirk,

LuaRocks certainly has this functionality. See the “luarocks.loader” module. It comes with LuaRocks.

It will use the LuaRocks dependency information to determine who is asking for a module, and what versions it is compatible with. And then it will go off and actually return/load a compatible version.

Note that LuaRocks installs the modules in a file-tree that is searchable by Lua using the module environment variables, but it also has its own repository. So whenever a file is installed with the same name, the last one wins in the file-system. But in the repository they will remain available side-by-side. The LuaRocks loader is then smart enough to find the proper rock from the repository.

Make sure you require “luarocks.loader” before loading the other modules.