Non-uniqueness of module names

[Dirk Laurie <dirk.laurie@...>]

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.