[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Non-uniqueness of module names
- From: Gabriel Bertilson <arboreous.philologist@...>
- Date: Fri, 12 Apr 2019 15:50:08 -0500
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.
local res, err = package.searchpath(module_name, package.path)
if not res then
res, temp_err = package.searchpath(module_name, package.cpath)
if not res then
return nil, err .. temp_err
It could be used in a custom `require` function that would return the
module and the path, something like this:
local real_require = require
local res = real_require(module_name)
if res then
return res, get_path(module_name)
Not the most efficient because it searches the paths twice.
On Fri, Apr 12, 2019 at 8:50 AM Dirk Laurie <email@example.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
> 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.