[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Non-uniqueness of module names
- From: Sean Conner <sean@...>
- Date: Sat, 20 Apr 2019 21:07:26 -0400
It was thus said that the Great Parke once stated:
> On Sat, Apr 20, 2019 at 2:12 PM Sean Conner <email@example.com> 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.
> 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:
which seems fine. A particular OS distribution can have, say, package.path
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:
> 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
And LuaRocks will handle Lua versions for you.
-spc (It seems compared to Python, Lua isn't doing half bad)