[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: require() relative to calling file
- From: Stephen Irons <stephen.irons@...>
- Date: Tue, 7 Feb 2017 15:23:44 +1300
On 4 February 2017 at 19:48, Russell Haley <firstname.lastname@example.org> wrote:
> I have counter arguments but that's not the point. The only reason I
> spoke up is because I ran into this myself when I was starting with
> Lua. The way it searches the current path and chooses the defaults to
> search is opaque to casual users. The simple fact is Lua searches a
> number of places for a variety of things to help the user out but
> negates this simple yet effective addition that won't break any other
> operating environment because you won't be using path separators if
> there is no filesystem. It provides huge functionality, doesn't break
> anything, provides continuity between that "other small operating
> system" that Lua supports, is 100% backwards compatible (because
> nobody could do it before) and is as simple as saving the results of a
> one time tokenization (is that the right word?). The best answer to
> "why not?" is "because that's not the way we did it before". Fair
> enough, but I agree with the OP that it's a puzzling omission. And
> this is coming from a guy who likes to start counting from 1.
In the abstract, it might make sense for Lua to also search in the
'script directory' for all of the reasons you state.
However, in the source code, it is package.searchpath() (file
loadlib.c, function searchpath()) that implements the way Lua finds
modules. searchpath() modifies the name of the module to find
(replacing '.' with the directory separator), then takes a list of
path templates (from package.path), replaces '?' with the modified
name of the module, and passes each in turn to the C standard function
fopen(). This code is all very straightforward, with no special cases.
It is fopen() and the underlying OS that happens to interpret the
symbol '.' as 'current directory' on most systems. On Windows in Lua
5.2 and later, the path templates use '!' to mean something similar (I
don't understand exactly what '!' means on Windows).
The point is that there is no special code in Lua that understands
'current directory': this is part of fopen() and the underlying OS
interpreting '.' or '!'
Currently, there is no special code in Lua that understands 'script
directory'. Furthermore, on POSIX systems at least, there is no symbol
that fopen() and the underlying OS will interpret as meaning 'script
It would be possible to add code to function package.searchpath() so
that it also searches the 'application directory'
* The concept of 'script directory' would need to be defined.
* A symbol (analogous to '.' in some versions of package path, not
the '.' in a module name) would need to be chosen to represent 'script
* A method to escape this new symbol would be needed in case that
symbol was needed in a pathname.
* This behaviour would need to be documented.
* This code would need to be implemented and tested on all systems.
It seems that the Lua developers chose not to take on this burden.
Like every decision, there are advantages and disadvantages. Some
advantages are that the code is simpler, and uses concepts that are
well defined. One disadvantage is that it is a bit more difficult to
make an application and its sub-modules work 'relative to the script