Re: Non-uniqueness of module names

[Sean Conner <sean@...>]

It was thus said that the Great Parke once stated:
> On Sat, Apr 20, 2019 at 2:12 PM Sean Conner <sean@conman.org> 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)