Re: require() relative to calling file

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

On Fri, Feb 3, 2017 at 1:14 PM, Sean Conner <sean@conman.org> wrote:
> It was thus said that the Great Russell Haley once stated:
>> On Fri, Feb 3, 2017 at 1:16 AM, Scott Morgan <blumf@blueyonder.co.uk> wrote:
>> > On 02/03/2017 07:34 AM, Russell Haley wrote:
>> >> But the question was what is the argument against the approach
>> >> described. ‎ It always has seemed to me that Lua goes to great length
>> >> to search relative paths and entirely negates to look in the
>> >> application path for no reason whatsoever. It was one of the most
>> >> confusing things when I first started looking at Lua.
>> >
>> >
>> > Lua does use the EXE path in Windows, but under *nix systems things
>> > aren't so simple. There's no guarantee that the path to the executable
>> > exists and no clear way to determine it even if it does[0] (some hacky,
>> > platform dependant ways, but nothing clean).
>>
>> How is that any different than the paths added via environment
>> variables or package paths? In fact, the majority of search parameters
>> will never exist (Have you seen some of the crazy search patterns
>> used?), but they are searched JUST IN CASE someone did something
>> fancy/stupid, but the path for the executing script in is not checked.
>
>   That's because *WINDOWS* makes the EXE path available to the application.
> Unix *DOES NOT*.  Take the following C program:
>
>         #include <stdio.h>
>         #include <stdlib.h>
>
>         int main(int argc,char *argv[])
>         {
>           printf("%s\n",argv[0]);
>           return EXIT_SUCCESS;
>         }
>
>   I ran the program:
>
>         GenericUnixPrompt> ./whatpath
>         ./whatpath
>
>   I then copied the program to a location covered by $PATH.
>
>         GenericUnixPrompt> whatpath
>         whatpath
>
>   So, where did I install 'whatpath'?  Here's $PATH:
>
> /home/spc/.luarocks/bin:/home/spc/bin:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/root/bin
>
>   Okay, I do have options.  If arg[0] only contains a program name (no path
> components like '/') then I *could* walk each element of $PATH, adding in
> arg[0] and checking the existence of the program to find where it's located.
> So now we have:
>
>         GenericUnixPrompt> whatpath
>         arg[0]: whatpath
>         path:   /home/spc/bin/whatpath
>
>   Okay, even in C this wasn't a terrible amount of code (around 40 lines or
> so to walk down $PATH) but you are still talking about string manipulation
> in C (and it took me a few passes to get correct---I think).  I'm even
> reasonably certain it will work on Windows, as is [1].
>
>   But this is something *UNIX* does not provide "out of the box."

But if the arg[0] contains path denoting characters (/,\), why not
parse out the path and add it to the search path for require? Then
both scenarios are intrinsically covered with *very little* overhead.
It's done once when the calling script is executed.

>
>> > See luaconf.h (search WIN32) and loadlib.c (search for windows.h)
>> >
>> > Personally, I go with a shell script wrapper that sets the LUA_PATH etc.
>> > environment vars before launching the app/Lua interpreter
>>
>> Yes, there are many ways around it, but again, Lua seems to go to
>> great lengths to use relative paths and search hither and yander but
>> negates the application path arbitrarily. I say arbitrarily because
>> there is no good reason to NOT search it (thus far).
>
>   Unix has no concept of an "application path".

Are we talking about Unix or Lua? I would argue Unix and "Lua on Unix"
 and even C assumes that the current path is the "application path",
which is why all these system searches the current path in various
system functions. In Lua, it searches the current path for require
modules even if the script is in a different directory! Also, what
would you think if "ls" only searched the current path when you
specified a path in your search string?

>And neither does C for that
> matter.  Remember, Lua uses the standard C library [2] and the C standard
> library makes no mention of paths (or directories for that matter).

Sure, you are correct. But as you pointed out, Lua is portable to
non-Unix systems that do not have path concepts, but it DOES use paths
in systems that support it. So, as I said, why not parse arg[0] for
appropriate path delimiters and use them when provided? "Because it's
hard" does not seem like a very good reason. Moreover, as you pointed
out parsing arg[0] for delimiters is not what would be consider a
difficult task (albeit C has surprised me before! ha ha).

So if I new NOTHING more about Lua than "the require module uses some
relative paths to find packages" (which is as much as most people will
probably know) and it didn't search the path of the executing script
when it is different from the current directory, I would say your
bonkers (which is what I thought when it didn't work). Why exclude
this simple addition? Because it's not easy in Unix (which I think you
have proven incorrect) again seems like a) a cop out (no offense) and
b) tuning what is supposed to be a generic scripting library for a
specific platform.

I think it would be much better to say:

On all platforms that support file systems, Lua will:
1) Search the current directory
2) Search the path of the executing script when it differs from the
current path (i.e. the user has specified extra path information)
3) Package.path and package.cpath (which has environment variables
appended if I understand correctly)

I could see it getting more complicated if a relative path was
specified, but environment variables can have relative paths too.

This next comment is not about you, Sean, but a general comment about
arguments made in Lua's defense: I think it's funny how on one side
some people argue that Lua is not C and not bound by it's constraints
and design guidelines, but on the other side the argument is made that
Lua uses standard C so is intrinsically tied to C idiosyncrasies? I
would categorize this as an arbitrary use of ISO C limitations for
covering a "not in my Unix" argument.

>> However:
>>
>> 1) It makes logical sense in terms of user expectation. Running
>>
>>     [user@computer~]$ lua ~/mylib/script.lua
>>
>> And NOT finding all the required modules causes a dissonance that the
>> user must overcome. Why force this when a dead simple solution is
>> present?
>
>   It's not necessarily simple under Unix.
>
>> 2) It makes your code more portable. By simply checking the
>> application path after the current path (or potentially vis-versa)
>> developers can package things together and users can now run
>> applications from anywhere without the requirement of a script. Why
>> force a user to write a wrapper?
>>
>> 3) If the windows version of Lua does indeed search the application
>> path, why use two different patterns when the solution is trivial?
>
>   So what *is* this trivial solution then?

Parse arg[0] for path delimiters and include that path in the search
criteria for modules. Trivial...

p.s. Thanks for the fun little discussion on Friday!

Russ