Re: Non-uniqueness of module names

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

Op So. 14 Apr. 2019 om 22:32 het Sean Conner <sean@conman.org> geskryf:
>
> It was thus said that the Great Abhijit Nandy once stated:
> > So why aren't the paths from where the modules are loaded, simply kept in a
> > table mapped to the module name?
>
>   Let's assume this happens.  package.locations[] contains the path from
> where a given module was loaded from.

The full filename, please. The distinction between module.so,
module.lua and module/init.lua is important.

> What types of checks could one
> realistically do given this information?  On my system, a module can appear
> in one of these paths:
>
>         /home/spc/.luarocks/share/lua/5.3/
>         /home/spc/.luarocks/lib/lua/5.3/
>         /usr/local/share/lua/5.3/
>         /usr/local/lib/lua/5.3/
>         ./
>
>   For a program I'm using, yes, I can check to see if module complex was
> loaded from "/home/spc/.luarocks/share/lua/5.3/complex.lua" but I can't
> release it that way for others to use.

It is not important to anticipate how the filename is used, only to
preserve the location where the module loader was found.

Simlar information is provided by several well respected software
products that satisfy a dependency from any of several sources.

* Un*x provides the command `which`.
* TeX displays on the console and writes to a log file every file that
it includes.
* Lua's debug.getinfo gives a field `source`.

Lua's default PATH and CPATH are much less ambitious than the paths of
Un*x or TeX, but the information is so basic that the question should
rather be why not than why.