Re: require() relative to calling file

[Russell Haley <russ.haley@...>]

On Mon, Feb 6, 2017 at 9:23 PM, Stephen Irons
<stephen.irons@clear.net.nz> wrote:
> On 4 February 2017 at 19:48, Russell Haley <russ.haley@gmail.com> 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.
>>
>> Cheers,
>>
>> Russ
>>
>
> 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
> directory'.
>
> It would be possible to add code to function package.searchpath() so
> that it also searches the 'application directory'

Thanks for that Stephen. The upside of this for me is I've started
reading the Lua source code. I briefly looked through loadlib.c but
didn't see what I was looking for (Duh Russell, how about start with
main in lua.c? I do way too much of this after 10 pm. lolz). So, I am
looking at it from the view that this would be mostly applicable to
the stand alone interpreter as anyone sophisticated enough to be
loading Lua any other way will not need this functionality. However,
that means two different usage signatures so I shall see what I come
up with. If the argument (script name) is passed, check for path
separators. If they exist, prepend it to package.path. In my little
world, it seems logical to start closest to the script and work
outwards when searching for modules. However, that seems to be the
opposite take of the Lua developers as per Mr. Laurie's email. I saw
the discussion about moving some env() function so I will also look
into that as well.

As there are numerous ways around this (including Mr. Donovans
fabulous Penlight library), I suppose it's all academic in the long
run. Thanks everyone for putting up with me!

Russ

>    * 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
> directory'
>
>    * 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
> directory'.
>
> Stephen Irons
>