Non-uniqueness of module names

classic Classic list List threaded Threaded
53 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Non-uniqueness of module names

Thijs Schreijer


On 12 Apr 2019, at 15:50, Dirk Laurie <[hidden email]> 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.

Hi Dirk,

LuaRocks certainly has this functionality. See the “luarocks.loader” module. It comes with LuaRocks.


It will use the LuaRocks dependency information to determine who is asking for a module, and what versions it is compatible with. And then it will go off and actually return/load a compatible version.

Note that LuaRocks installs the modules in a file-tree that is searchable by Lua using the module environment variables, but it also has its own repository. So whenever a file is installed with the same name, the last one wins in the file-system. But in the repository they will remain available side-by-side. The LuaRocks loader is then smart enough to find the proper rock from the repository.

Make sure you require “luarocks.loader” before loading the other modules.

Hth
Thijs


Reply | Threaded
Open this post in threaded view
|

Re: Non-uniqueness of module names

Dirk Laurie-2
In reply to this post by Roberto Ierusalimschy
Op Ma. 15 Apr. 2019 om 14:45 het Roberto Ierusalimschy
<[hidden email]> geskryf:

>
> I am not sure you are aware that the module itself already gets
> this information:
>
> ---- file temp.lua
> print(...)
>
> $ lua -l temp
>     --> temp    ./temp.lua
>
> Maybe 'require' could simply return this information as a second result?

That would be perfect, thanks.

-- Dirk

Reply | Threaded
Open this post in threaded view
|

Re: Non-uniqueness of module names

Dirk Laurie-2
In reply to this post by Luiz Henrique de Figueiredo
Op Ma. 15 Apr. 2019 om 18:44 het Luiz Henrique de Figueiredo
<[hidden email]> geskryf:
> > 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
>
> My modules contain a "version" field that can be used for that.
> If only module writers could agree to have that field and on what is
> inside it...

I would be more comfortable with _VERSION, with the Lua interpreter
itself, as "master module", already adhering to that convention :-)

Reply | Threaded
Open this post in threaded view
|

Re: Non-uniqueness of module names

Roberto Ierusalimschy
> I would be more comfortable with _VERSION, with the Lua interpreter
> itself, as "master module", already adhering to that convention :-)

+1.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Non-uniqueness of module names

Fabio Mascarenhas
In reply to this post by Thijs Schreijer
Hi Thijs,

On Tue, Apr 16, 2019 at 5:23 AM Thijs Schreijer <[hidden email]> wrote:

>
> LuaRocks certainly has this functionality. See the “luarocks.loader” module. It comes with LuaRocks.
>
> https://github.com/luarocks/luarocks/blob/master/src/luarocks/loader.lua
>
> It will use the LuaRocks dependency information to determine who is asking for a module, and what versions it is compatible with. And then it will go off and actually return/load a compatible version.
>
> Note that LuaRocks installs the modules in a file-tree that is searchable by Lua using the module environment variables, but it also has its own repository. So whenever a file is installed with the same name, the last one wins in the file-system. But in the repository they will remain available side-by-side. The LuaRocks loader is then smart enough to find the proper rock from the repository.
>
> Make sure you require “luarocks.loader” before loading the other modules.
>

Unfortunately this does not work for transitive dependencies,
specially using require, even if you take care to clear the require
cache.

Take these two simple rocks, each of which depends on another rock
which provides a 'complex' module:

------- uselcomplex-scm-1.rockspec ---------
package = "uselcomplex"
version = "scm-1"
source = {
  url = ""
}
description = {
   summary = "A rock which uses lcomplex's complex",
}
dependencies = {
   "lua >= 5.1, < 5.4",
   "lcomplex == 20180729-1"
}
build = {
  type = "builtin",
  modules = {
    uselcomplex = "uselcomplex.lua"
  }
}
-------

------- uselcomplex.lua ---------
local complex = require "complex"

return {
  test = function ()
    return complex.version
  end
}
-------

------- useluafft-scm-1.rockspec ---------
package = "useluafft"
version = "scm-1"
source = {
  url = ""
}
description = {
   summary = "A rock which uses luafft's complex",
}
dependencies = {
   "lua >= 5.1, < 5.4",
   "luafft == 1.2"
}
build = {
  type = "builtin",
  modules = {
    useluafft = "useluafft.lua"
  }
}
-------

------- useluafft.lua ---------
local complex = require "complex"

return {
  test = function ()
    return complex.version
  end
}
-------

You can install both in your rocks tree, and will get two different
"complex" modules. Now run this:

------- conflict.lua --------
require "luarocks.loader"

local uselcomplex = require "uselcomplex"
package.loaded.complex = nil
local useluafft = require "useluafft"

print(useluafft.test())
print(uselcomplex.test())
-------

This will print:

complex number library for Lua 5.3 / Jul 2018
complex number library for Lua 5.3 / Jul 2018

Changing the order of the two requires so  "useluafft" is required
first (again, cleaning the package cache for "complex" between the
two) prints (luafft's complex does not have a version field):

nil
complex number library for Lua 5.3 / Jul 2018

This is a tractable issue, the LuaRocks loader would need to keep a
stack where the top of the stack is the rock/version pair for the
module we are going to load next (popping the stack after loading it),
and for efficiency the manifest could also need to have a
(rock/version, bare_module) -> file_name mapping (which would replace
the need for the current dynamic loader context) or a (rock/version,
bare_module) -> other_rock/version mapping.

I think me and Hisham had discussed that several years ago in the
transition from LuaRocks requiring its own require function to playing
nice with the Lua module system and just adding a loader, but my
memory is fuzzy. :-)

If you remove the line to clear package.loaded it is even worse,
because require caches the module based on the bare module name:

nil
nil

That is only solvable by having LuaRocks provide its own require
function and monkey-patching the global require (which it used to).

--
Fabio Mascarenhas

Reply | Threaded
Open this post in threaded view
|

Re: Non-uniqueness of module names

Fabio Mascarenhas
On Wed, Apr 17, 2019 at 5:37 PM Fabio Mascarenhas <[hidden email]> wrote:
>
>
> That is only solvable by having LuaRocks provide its own require
> function and monkey-patching the global require (which it used to).
>

On second thought, things are not actually that bleak, since
ll_require uses regular get/set instead of the raw versions, so the
LuaRocks loader could install a metatable in package.loaded to replace
it with a package cache under the control of LuaRocks.

--
Fabio Mascarenhas

Reply | Threaded
Open this post in threaded view
|

Re: Non-uniqueness of module names

Dennis Fischer
In reply to this post by Dirk Laurie-2
> The Lua ecosystem will never be worth that name as long as there is no
> way to address the module naming issue.

There is one: Naming modules correctly

Lua doesn't make any assumptions about what a module is (It can even be an environment variable, see recent email). Module authors are responsible for naming their modules in a smart way. Same goes for rock authors. Calling your module "generic", but then calling the rock "lua-very-specific" is just asking for problems with clashing module names.

If you want to make sure to load modules only from a very specific location, you can just write your own `require_custom` function that loads lua modules with `dofile` and caches them. Also be sure to sandbox the new module to also use the require function you provided for any submodules it may load.

For Lua in general though, why would it build in additional checks to fix someone elses problems (i.e. poorly named modules)? That would just mean increasing complexity with little to no benefit.
Reply | Threaded
Open this post in threaded view
|

Re: Non-uniqueness of module names

Dirk Laurie-2
Op Do. 18 Apr. 2019 om 11:23 het Dennis Fischer
<[hidden email]> geskryf:

> For Lua in general though, why would it build in additional checks to fix someone elses problems (i.e. poorly named modules)? That would just mean increasing complexity with little to no benefit.

The problem is not the well-named module that I actually intend to
use. It is another module that behaves inconsiderately, muscling its
way into the search path ahead of a previously installed module.

I must still study Thys's suggestion of using loader.lua. This may
well be the ultimate answer.

Reply | Threaded
Open this post in threaded view
|

Re: Non-uniqueness of module names

Hisham
In reply to this post by Roberto Ierusalimschy
On Tue, 16 Apr 2019 at 18:43, Roberto Ierusalimschy
<[hidden email]> wrote:
>
> > I would be more comfortable with _VERSION, with the Lua interpreter
> > itself, as "master module", already adhering to that convention :-)

The Lua interpreter does things that modules are not supposed to do,
such as loading a bunch of globals. It is an example of "main program"
behavior, not "module behavior".

> +1.

But what about what the Lua reference manual says about using names of
that sort:

"As a convention, programs should avoid creating names that start with
an underscore followed by one or more uppercase letters (such as
_VERSION)."

It even uses _VERSION as the example of what _not_ to do! :) I
understand that this can be interpreted as meaning "globals", and for
a while I thought that was the case. But then I've had to fix other
people's code in the wild that did not follow the recommendation above
and used _ENV as a regular *local* variable name in Lua 5.1, and
stopped working when Lua 5.2 came around. Now, when I read "names"
there I take it to mean any kind of name (locals, globals, module
names and members, etc). It does sound unlikely that a future version
of Lua would decide to make a particular module member name take a
reserved meaning, but if you asked me back in Lua 5.1 days I'd also
say it was unlikely that this would happen to a local variable name
too.

I know I could have expanded the scope of my interpretation minimally
to have it mean "variables", but now I do the safe thing and avoid
underscore-uppercase names of all kinds. I understand that in this
particular case _VERSION is probably safe for the future (Roberto's +1
is a strong indication, of course, but language authors have changed
their minds before. :) ) In any case, following the manual's
recommendation has proven to be a safe bet in my own code.

-- Hisham

Reply | Threaded
Open this post in threaded view
|

Re: Non-uniqueness of module names

Peter Aronoff
Hisham <[hidden email]> wrote:

> Roberto Ierusalimschy <[hidden email]> wrote:
> >
> > > I would be more comfortable with _VERSION, with the Lua interpreter
> > > itself, as "master module", already adhering to that convention :-)
>
> The Lua interpreter does things that modules are not supposed to do,
> such as loading a bunch of globals. It is an example of "main program"
> behavior, not "module behavior".
>
> > +1.
>
> But what about what the Lua reference manual says about using names of
> that sort:
>
> "As a convention, programs should avoid creating names that start with
> an underscore followed by one or more uppercase letters (such as
> _VERSION)."
>
> It even uses _VERSION as the example of what _not_ to do!

Thanks for asking this question, Hisham! I was too shy, but I had the
exact same thought. A few years ago, I rewrote all my modules *not* to use
_VERSION, _AUTHOR, etc.[1]

Maybe I didn’t need to rewrite them after all?

Best, P

[1] What I do now is export functions version(), author(), etc. It works
    out pretty much the same.

    https://github.com/telemachus/split/blob/master/src/split.lua#L129-L143

--
We have not been faced with the need to satisfy someone else's
requirements, and for this freedom we are grateful.
    Dennis Ritchie and Ken Thompson, The UNIX Time-Sharing System

Reply | Threaded
Open this post in threaded view
|

Re: Non-uniqueness of module names

Dirk Laurie-2
In reply to this post by Hisham
Op Do. 18 Apr. 2019 om 16:52 het Hisham <[hidden email]> geskryf:

> It even uses _VERSION as the example of what _not_ to do! :) I
> understand that this can be interpreted as meaning "globals", and for
> a while I thought that was the case. But then I've had to fix other
> people's code in the wild that did not follow the recommendation above
> and used _ENV as a regular *local* variable name in Lua 5.1, and
> stopped working when Lua 5.2 came around.

Using _ENV as a local name is even an idiom nowadays,

Reply | Threaded
Open this post in threaded view
|

Re: Non-uniqueness of module names

Dirk Laurie-2
In reply to this post by Peter Aronoff
Op Do. 18 Apr. 2019 om 21:16 het Peter Aronoff <[hidden email]> geskryf:

> Thanks for asking this question, Hisham! I was too shy, but I had the
> exact same thought. A few years ago, I rewrote all my modules *not* to use
> _VERSION, _AUTHOR, etc.[1]
>
> Maybe I didn’t need to rewrite them after all?

I've always thought about reserved names in a Lua 5.1 sort of way:
such global variables are reserved, but in one's own tables it's OK.
But you have now forced me to RTFM. I'm jumping over 5.2 because it
does not seem to have the same retro appeal that 5.1 has.

Under "Lexical conventions"
5.1: As a convention, names starting with an underscore followed by
uppercase letters (such as _VERSION) are reserved for internal global
variables used by Lua.
5.3: As a convention, programs should avoid creating names that start
with an underscore followed by one or more uppercase letters (such as
_VERSION).

Under "Registry"
5.1 and 5.3: Any C library can store data into this table, but it
should take care to choose keys different from those used by other
libraries, to avoid collisions.
5.3: As with variable names, string keys starting with an underscore
followed by uppercase letters are reserved for Lua.

The letter of the law is now "avoid creating names that start with an
underscore followed by one or more uppercase letters".

But is that the spirit of the law? The mere fact that the registry has
been singled out in Lua 5.3 seems to imply that the issue is less
crucial in other tables than in the registry and the global
environment.

Ah, but in Lua 5.3 any table could in principle be the value _ENV. So
by the letter of the law it's no longer "internal global variables"
only, it's "names" in general.

Does "reserved for Lua" mean "never change this value"? I think not.
If so, the variable could have been made read-only. I think it means
"use it in the way that Lua uses it". By that logic, _VERSION in a
table, and particularly a table that is used as a library, should give
version information about that table.

Do we have precedents? No. Roberto (in `lpeg`) and Luiz (in `mathx`
etc) use a plain lowercase "version". (For a string, though, not a
function as Peter has it.)

But would it not be a useful convention?

Reply | Threaded
Open this post in threaded view
|

Re: Non-uniqueness of module names

Mitchell-2
Hi,

On Fri, 19 Apr 2019, Dirk Laurie wrote:

> Op Do. 18 Apr. 2019 om 21:16 het Peter Aronoff <[hidden email]> geskryf:
>
>> Thanks for asking this question, Hisham! I was too shy, but I had the
>> exact same thought. A few years ago, I rewrote all my modules *not* to use
>> _VERSION, _AUTHOR, etc.[1]
>>
>> Maybe I didn’t need to rewrite them after all?
>
> I've always thought about reserved names in a Lua 5.1 sort of way:
> such global variables are reserved, but in one's own tables it's OK.
>
> [snip]
Back in Lua 5.1 or 5.2 I had an issue with having a "_M" field in my tables (not globally). I don't recall the exact problem, but I think it was related to packages and modules reading and/or storing something in "_M".

Cheers,
Mitchell
Reply | Threaded
Open this post in threaded view
|

Re: Non-uniqueness of module names

Tim Hill
In reply to this post by Dirk Laurie-2


> On Apr 12, 2019, at 6:50 AM, Dirk Laurie <[hidden email]> 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.
>


+1 .. imho this is one of the weaker aspects of Lua. While I realize Lua is primarily an embedded language (and I use it as such), I think this model carries over too much (perhaps unconsciously) into the module system, which only really works if (a) you have written the script yourself and (b) you control ALL the module installs. This is of course fine if you are embedding, but basically means creating a general-purpose Lua script for use by others is fraught with difficulties.

As for suggestions .. I’m sure many people here know the various design patterns, but in Lua-land it all really comes down to two issues:

1. A unified identity system for modules (note I said identity, not name). This can’t depend on balkanized issues such as paths either.
2. A recommended pattern for using a module within code that handles mapping module identities to bound names.

I realize Robero et al feel that Lua should be as policy-free as possible, but I think Lua and the community would really benefit from some guidance here.

—Tim







Reply | Threaded
Open this post in threaded view
|

Re: Non-uniqueness of module names

Sean Conner
It was thus said that the Great Tim Hill once stated:

> > On Apr 12, 2019, at 6:50 AM, Dirk Laurie <[hidden email]> wrote:
> >
> > The Lua ecosystem will never be worth that name as long as there is no
> > way to address the module naming issue.
>
> +1 .. imho this is one of the weaker aspects of Lua. While I realize Lua
> +is primarily an embedded language (and I use it as such), I think this
> +model carries over too much (perhaps unconsciously) into the module
> +system, which only really works if (a) you have written the script
> +yourself and (b) you control ALL the module installs. This is of course
> +fine if you are embedding, but basically means creating a general-purpose
> +Lua script for use by others is fraught with difficulties.
>
> As for suggestions .. I’m sure many people here know the various design
> patterns, but in Lua-land it all really comes down to two issues:
>
> 1. A unified identity system for modules (note I said identity, not name).
> This can’t depend on balkanized issues such as paths either.
> 2. A recommended pattern for using a module within code that handles
> mapping module identities to bound names.

  Okay ... how would you like to see this work?  Also, how do other
langauges like Python or Ruby handle this?  How does npm handle this, given
that has like a zillion modules?

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: Non-uniqueness of module names

Coda Highland
On Sat, Apr 20, 2019 at 4:12 PM Sean Conner <[hidden email]> wrote:
  Okay ... how would you like to see this work?  Also, how do other
langauges like Python or Ruby handle this?  How does npm handle this, given
that has like a zillion modules?
 
npm requires that modules have unique names (first come first serve) and the import name always matches the directory containing the module. The import scheme also does aggressive namespacing so you have to go out of your way to do stuff that might screw up some other module's transitive dependencies.

There's a lot to hate about npm, but that part at least works pretty robustly.

/s/ Adam
Reply | Threaded
Open this post in threaded view
|

Re: Non-uniqueness of module names

Sean Conner
It was thus said that the Great Coda Highland once stated:
> On Sat, Apr 20, 2019 at 4:12 PM Sean Conner <[hidden email]> wrote:
>
> >   Okay ... how would you like to see this work?  Also, how do other
> > langauges like Python or Ruby handle this?  How does npm handle this, given
> > that has like a zillion modules?
> >
>
> npm requires that modules have unique names (first come first serve) and

  Okay, pretty much the same as Lua then.

> the import name always matches the directory containing the module. The

  Again, pretty much the same as Lua.

> import scheme also does aggressive namespacing so you have to go out of
> your way to do stuff that might screw up some other module's transitive
> dependencies.

  Okay, so how does *this* work then?

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: Non-uniqueness of module names

Parke
In reply to this post by Sean Conner
On Sat, Apr 20, 2019 at 2:12 PM Sean Conner <[hidden email]> wrote:
> Okay ... how would you like to see this work?  Also, how do other
> langauges like Python or Ruby handle this?

I don't know how Python handles it, but I remember reading ESR's
criticisms of Python recently.

http://esr.ibiblio.org/?p=8161

-Parke

Excerpt:

The final entry in our trio of tribulations is the dumpster fire that
is Python library paths. This has actually been a continuing problem
since GPSD and has bitten NTPsec pretty hard – it’s a running sore on
our issue tracker, so bad that were’re seriously considering moving
our entire suite of Python client tools to Go just to get shut of it.

The problem is that where on your system you need to put a Python
library module in order so that a Python main program (or other
library) can see it and load it varies in only semi-predictable ways.
By version, yes, but there’s also an obscure distinction between
site-packages, dist-packages, and what for want of any better term
I’ll call root-level modules (no subdirectory under the version
directory) that different distributions and even different application
packages seem to interpret in different and incompatible ways. The
root of the problem seems to be that good practice is under-specified
by the Python dev team.

This is particular hell on project packagers. You don’t know what
version of Python your users will be running, and you don’t know what
the contents of their sys.path (library load path variable). You can’t
know where your install production should put things so the Python
pieces of your code will be able to see each other. About all you can
do is shotgun multiple copies of your library to different plausible
locations and hope one of them intersects with your user’s load path.
And I shall draw a kindly veil over the even greater complications if
you’re shipping C extension modules…

Paralysis around the GIL, the Python 3 strings botch, the library-path
dumpster fire – these are signs of a language that is aging, grubby,
and overgrown. It pains me to say this, because I was a happy Python
fan and advocate for a long time. But the process of learning Go has
shed a harsh light on these deficiencies.

Reply | Threaded
Open this post in threaded view
|

Re: Non-uniqueness of module names

Sean Conner
It was thus said that the Great Parke once stated:

> On Sat, Apr 20, 2019 at 2:12 PM Sean Conner <[hidden email]> wrote:
> > Okay ... how would you like to see this work?  Also, how do other
> > langauges like Python or Ruby handle this?
>
> I don't know how Python handles it, but I remember reading ESR's
> criticisms of Python recently.
>
> http://esr.ibiblio.org/?p=8161
>
> -Parke
>
> Excerpt:
>
> The final entry in our trio of tribulations is the dumpster fire that
> is Python library paths. This has actually been a continuing problem
> since GPSD and has bitten NTPsec pretty hard – it’s a running sore on
> our issue tracker, so bad that were’re seriously considering moving
> our entire suite of Python client tools to Go just to get shut of it.
>
> The problem is that where on your system you need to put a Python
> library module in order so that a Python main program (or other
> library) can see it and load it varies in only semi-predictable ways.
> By version, yes, but there’s also an obscure distinction between
> site-packages, dist-packages, and what for want of any better term
> I’ll call root-level modules (no subdirectory under the version
> directory) that different distributions and even different application
> packages seem to interpret in different and incompatible ways. The
> root of the problem seems to be that good practice is under-specified
> by the Python dev team.

  I don't see Lua having this issue.  It's pretty clear where Lua gets its
modules from, package.path and package.cpath.  They default to:

package.path
        /usr/local/share/lua/5.3/?.lua
        /usr/local/share/lua/5.3/?/init.lua
        /usr/local/lib/lua/5.3/?.lua
        /usr/local/lib/lua/5.3/?/init.lua
        ./?.lua
        ./?/init.lua

package.cpath
        /usr/local/lib/lua/5.3/?.so
        /usr/local/lib/lua/5.3/loadall.so
        ./?.so

which seems fine.  A particular OS distribution can have, say, package.path
defined as:
        /usr/local/share/lua/5.3/?.lua
        /usr/local/share/lua/5.3/?/init.lua
        /usr/local/lib/lua/5.3/?.lua
        /usr/local/lib/lua/5.3/?/init.lua
        /usr/share/lua/5.3/?.lua
        /usr/share/lua/5.3/?/init.lua
        /usr/lib/lua/5.3/?.lua
        /usr/lib/lua/5.3/?/init.lua
        ./?.lua
        ./?/init.lua

But LuaRocks can certainly be configued to handle the installation for you.
In fact, I have LuaRocks set up so that anything I install goes directly
into my home directory:

package.path
        /home/spc/.luarocks/share/lua/5.3/?.lua
        /home/spc/.luarocks/share/lua/5.3/?/init.lua
        /home/spc/.luarocks/lib/lua/5.3/?.lua
        /home/spc/.luarocks/lib/lua/5.3/?/init.lua
        /usr/local/share/lua/5.3/?.lua
        /usr/local/share/lua/5.3/?/init.lua
        /usr/local/lib/lua/5.3/?.lua
        /usr/local/lib/lua/5.3/?/init.lua
        ./?.lua
        ./?/init.lua

> This is particular hell on project packagers. You don’t know what
> version of Python your users will be running, and you don’t know what
> the contents of their sys.path (library load path variable).

  Again, this doesn't really affect Lua.  Lua 5.1 will use the environment
variable LUA_PATH to modify package.path; Lua 5.2 will use LUA_PATH_5_2,
and if that doesn't exit, LUA_PATH.  Lua 5.3 uses LUA_PATH_5_3 (and again,
only if that doesn't exist will it use LUA_PATH).  I have all three defined
(mainly for testing to make sure my published modules with with Lua 5.1 or
greater).  

  And LuaRocks will handle Lua versions for you.

  -spc (It seems compared to Python, Lua isn't doing half bad)


Reply | Threaded
Open this post in threaded view
|

Re: Non-uniqueness of module names

Coda Highland
In reply to this post by Sean Conner


On Sat, Apr 20, 2019 at 5:33 PM Sean Conner <[hidden email]> wrote:
It was thus said that the Great Coda Highland once stated:
> On Sat, Apr 20, 2019 at 4:12 PM Sean Conner <[hidden email]> wrote:
>
> >   Okay ... how would you like to see this work?  Also, how do other
> > langauges like Python or Ruby handle this?  How does npm handle this, given
> > that has like a zillion modules?
> >
>
> npm requires that modules have unique names (first come first serve) and

  Okay, pretty much the same as Lua then.

> the import name always matches the directory containing the module. The

  Again, pretty much the same as Lua.

Pretty much, but not entirely. The fact that some modules don't do this is one of the reasons this thread has come up at all.
 
> import scheme also does aggressive namespacing so you have to go out of
> your way to do stuff that might screw up some other module's transitive
> dependencies.

  Okay, so how does *this* work then?

  -spc

Mostly, ironclad module scoping. Each file has its own global scope, and you have to explicitly push things out into the actual global-global scope if that's something you REALLY want to do -- and there's basically never a good reason to unless you're building automated testing tools. (And even then it's not a GREAT idea. Those do indeed end up stepping on toes.)

Duplicated dependencies don't necessarily even get mapped onto each other. If they're not the same module (with compatibility determined by the importer's explicitly-requested versioning information) then you can actually end up with two copies of the module loaded in, and since they're different modules with isolated namespaces they don't interfere with each other. It's not the BEST solution to dependency hell because it leads to bloating and bugfixes that don't get applied consistently, but it does mean that a transitive dependency is a little less likely to screw you over.

/s/ Adam
123