Re: To all Lua rock maintainers, take 2 (now with human-friendly reporting), you help is appreciated again

On 13 September 2015 at 22:42, Sean Conner <sean@conman.org> wrote:

I still don't understand how "org.conman.errno" contends with
"org.conman.env". Okay, I understand that you assume that both are part of
a module called "org" but that's incorrect. It's *NOT*. They are two
separate modules that happen to share a common prefix. I'm guessing that
had I named them org-conman-env and org-conman-errno then there would be be
no issue, right? But why, if they contain periods, are they suddenly one
module?

OK, let me clarify this point.

The rock names are completely irrelevant to my build process (and to my package manager), the only thing that matters is where the files gets installed, i.e. what strings must be passed to require() for the given module.

More precisely, only the root directories are relevant, so for instance for luasocket we would have: socket, mime, ltn12.

In this case, luasocket has got hold of these 3 module names.

Why only roots? Because in general it is not possible to discover in which exact way require() must be called (i.e. to know wether org.conman.errno really conflicts with org.conman.env or not) without adding additional meta-data.

And I am not keen on doing this because I do not believe the complications are worth the advantage.

I really have 1 directory <-> 1 package and it is way easier this way (and dots are sub-directories in Lua, at least with the standard loaders/searchers).

The ULua main page explains how, even though some parts are still missing.

> require "org.conman.errno"
> require "org.conman.env"
> require "org.conman.table"
> require "org.conman.net"
> require "org.conman.syslog"
> require "org.conman.math"
> require "org.conman.signal"
> org.conman.table.show(package.loaded)
org.conman.signal-posix table: 0x9579178
string table: 0x955b618
org.conman.table table: 0x956eff8
package table: 0x955ba50
_G table: 0x955a450
os table: 0x955d3c8
table table: 0x955b100
math table: 0x955df90
coroutine table: 0x955b718
org.conman.syslog table: 0x956f5e0
org.conman.env table: 0x9570ec0
io table: 0x955cbc0
org.conman.errno table: 0x956cd20
debug table: 0x955e990
org.conman.signal table: 0x9579178
org.conman.math table: 0x957c260
org.conman.net table: 0x95780e0

Yes, the dots are significant in that they label both a table (within Lua)
and a path (on the system) to where the module resides. But that's (in my
opinion) an internal detail. Yes, there are some modules where loading the
top level will load all the "sub-modules" (for lack of a better term) but
not all. You cannot load "org" and get all my modules. There *IS* no
module "org" (there is no module "org.conman" either).

The fact that 'sub-modules' cannot be accessed by requiring the root it's not a problem at all.

Indeed I am doing the same here:

http://www.scilua.org/sci.html

The only difference is that I have a single package (would be a Lua rock here) for the whole 'sci'.

And your project shows *why* I went with namespacing my modules the way I
did. You have "math-evol", but not "math-rugekutta" because the former
claimed the "Math" module. And the only reason why "math-evol" didn't
conflich with "math-rugekutta" is because of the order you process the
modules. *This* is where I can see a "contending module", because "Math" ==
"Math". "org.conman.env" ~= "org.conman.errno". You need to treat the
entire module name (dots included) as the name.

To be honest my plan here is to remove math-evol as well (for sure it cannot stay as math):

require 'math.evol'

is confusing, as it seems to be somehow related to the Lua global math library and/or seems to be a Lua extension by the Lua team which is not the case.

By the way, the choice of an uppercase name for the module introduces additional OS-dependent behaviour.

Similarly, having '-' in the module name influence the standard Lua C-loader, so it's not a great idea either.

You have "org.conman.env" listed as "org", which is wrong. You have
"love-ora" listed as "ora", which is wrong. You have a bunch of "lusty-*"
modules, which is correct, but you let that slide because it's a "flat"
namespace.

It is not wrong, love-ora is the Lua rock name, but the module that gets installed is 'ora' not 'love-ora'.

Indeed, you use it by:

local ora = require 'ora' -- not require 'love-ora'

Sorry to harp on this, but how you determine "contending modules" is
partially broken.

-spc (Don't worry, I have more comments ... )

No worries, hopefully the above clarifies the reasons for the choices I made.

I understand these choices are inconvenient in some scenarios, but I believe the advantages overweights the disadvantages.

Stefano