lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Am 05.02.2017 um 12:42 schröbte Daurnimator:
On 4 February 2017 at 20:23, Sean Conner <sean@conman.org> wrote:
  Where do you add the "application path"?  Do you prepend it to
package.path?  Or append it to package.path?

You don't want to modify package.path for this type of functionality.
A key note is that the string you pass to the `require` function is
what the module is saved under in `package.loaded`.
It *has* to be something a function that wraps or re-implements
`require` itself.

Now I ask: why are we taking about this in relation to file systems?

Because this is supposed to simplify deployment (I think), so you want exactly the `utility.lua` module right next to you _on the filesystem_, not some other module with a matching name somewhere on LUA_PATH. But you are right that `package.loaded` gets in the way. We'd probably need some form of private module namespaces for this.

package searchers can be abstract, and don't have to be bound by a
file system layout.
I think the only reasonable way to accomplish a 'relative require' is
to use the *current* module path as a prefix.
Assuming the current file was loaded with require, this can be done as
Soni notes: `require((...)..".mysubmodule")`

Only if you are ok with `/usr/local/lib/lua/5.2/A.lua` potentially loading `/opt/lib/5.2/A/mysubmodule.lua`. This issue popped up some times with two LuaRocks installations (one in `/usr` via the package manager, the other in `/usr/local`), but I believe in those cases the problem was between the main script and the first require'd module, not between two require'd modules.


[...]

Back when I was first starting with lua, I did find myself wanting
relative require.
However as time has gone on I wanted it less and less, and now don't
have any desire for it at all.

I think the main desire for a relative require was a reluctance to
name my projects while I was working on them.
If I had a sub-module 'foo' that relied on a sub-module "bar", I'd
have to name the whole project!

And the deployment can be simplified with an amalgamation script -- `package.preload` takes precedence over the usual module locations.

Philipp