Re: Non-uniqueness of module names

[Gabriel Bertilson <arboreous.philologist@...>]

I've used a function like this, which returns the path of a module, or
else `nil` and the string containing the paths that were searched.

function get_path(module_name)
    local res, err = package.searchpath(module_name, package.path)
    if not res then
        local temp_err
        res, temp_err = package.searchpath(module_name, package.cpath)
        if not res then
            return nil, err .. temp_err
        end
    end
    return res
end

It could be used in a custom `require` function that would return the
module and the path, something like this:

local real_require = require
function require(module_name)
    local res = real_require(module_name)
    if res then
        return res, get_path(module_name)
    end
end

Not the most efficient because it searches the paths twice.

— Gabriel

— Gabriel



On Fri, Apr 12, 2019 at 8: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.
>