Re: Non-uniqueness of module names

[Gerhard Sittig <gerhard.sittig@...>]

On Mon, 2019-04-15 at 09:14 +0200, Dirk Laurie wrote:
>
> 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`.

That's a nice example.

The which(1) utility only works for input which happens to be an
executable file somewhere in a path.  This need not match what
actually happens (or happened) when the argument to which(1) got
invoked or will get invoked.  Besides executables files there are
also functions and aliases and builtin commands.  Things
addressable by some path is only a subset of the problem space.

Execution of the which(1) command also happens at a different
point in time than the execution of the executable that you want
to gather information about.  So the result may not mean a thing,
or may be wrong and misleading.  This translates to looking up
the module's content and thus assumed behaviour and running the
module at different points in time.

There are other approaches which are equally unreliable.  Lookup
in proc(5) how the process got started, and the information won't
tell you much.  The result can have become obsolete, need not be
correct, need not be there at all, may return a different result
at the time you query the detail (or query again).  This is
similar to pasing to the module at runtime what was gathered at
load time -- need not mean a thing.

Some platforms supported by Lua may not even have the notion of
"a path" to a module.  You may assume a specific environment
which does not necessarily translate well everywhere.  There were
examples of builtin and preloaded modules.  There were examples
of modules loaded from volatile storage (ZIP archives, network
sources, pipes, strings, etc).


Assuming a specific use at the OP's, namely to tell different
modules of the same name apart, it's more reliable to test
versions, or even better test the availability of features or
their behaviour.  Very much what some Lua interpreter version
checks do.  Because the initial question was how to tell those
different modules apart, was it not?

Insisting in specific filenames (if they even exist) seems to be
just a workaround after the actual problem of telling module
behaviour apart was not available (or was not considered, or one
of several approaches was picked early without considering other
approaches).


> 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.

Hmm.  Wasn't "why not?" the wrong approach to "selling" a
suggested change to the Lua authors? :)  When you expect them to
consider a change or extension, they do want to know _why_ they
should bother adding and then maintaining that extension ...
There should be a real reason why a change should be made, not a
lack of (spoken, and agreed on) reasons to reject the suggestion.


virtually yours
Gerhard Sittig
--
     If you don't understand or are scared by any of the above
             ask your parents or an adult to help you.