Re: changes in 'require'

[Roberto Ierusalimschy <roberto@...>]

> Any reason for this? [require failing on parent modules]

We think it is more simple and more reliable. And we don't see good
arguments against that.


> The separation of binaries into lib and scripts into share is
> in accordance with the Filesystem Hierarchy Standard, I hope.

It is, but as you said, files in lib don't need to be architecture
dependent. It seems much simpler to install a package with all its
modules together under the same directory. (Python, for instance, puts
all its libraries in /usr/lib. Perl too. Tcl too. Your own suggestion
for installing Luasocket puts .so and .lua under the same directory.)


> 1) Lua modules before C.
> I think this is retrograde step. [...]

That may be true. We want more input on that topic. About the change
being disruptive, I though that conflicting C and Lua modules should
be the exception rather the norm (as Tomas pointed out).


> 2) Search path. Am I to understand that the meaning of also using the
> "C search path" means that you intend to search the %PATH% or do you
> mean package.cpath?

It only means that the default path for Lua modules will include
"/usr/local/lib/...". It's a change only in the defaults.


> 3) There seems to be an assumption that require will only be used
> on systems with hiearchical file systems. There are three flat world
> environments that I use. I trust that the current resstructuring will 
> take into account flat filing systems.

As far as I can see the current changes (I wouldn't call that a
"resstructuring") are "orthogonal" to hiearchical file systems.  (Except
for the default pathes, which of course assume a hiearchical file
system).


> The ONLY problem that we have had with work6 require is the question
> of how to boot these preloads? This, as I read it, was Diego's original
> question. An external Lua script (like init.lua) defeats the original aim
> of loading the lua code from DLLs.

There is not need of an external Lua script. The whole point of that
kind of DLL is to have a "parent" module (at least to preload its
descendants). The point about adding a init.lua is for packages that
naturally do not have a parent module.


> I have a third suggestion for a change to require:
> 
> Don't load the names into the global namespace by default.

Require has never done that. Modules do.

-- Roberto