Re: Upcoming change to perl: current directory in @INC
On Thu, 08 Sep 2016 at 08:44:54 -0700, Russ Allbery wrote:
> I don't see any inherent reason why that
> should have to be the case (other than, of course, that this Python
> behavior is long-standing and lots of software depends on it
I suspect that Python scripts relying on their own directory being
put on sys.path are going to be a lot more common than Perl scripts
relying on the current working directory being in @INC. The Perl
script author doesn't (usually) control the current working directory
at the time of invocation, whereas the Python script author usually
does control where the script gets installed relative to its required
library.
In particular, this is quite a common idiom, because it's one of the
few ways you can have private Python modules (and hence not have to
care about having a stable API, which isn't in-scope for every project)
without explicitly setting sys.path to a value hard-coded at install time:
Source tree:
~/src/myapp or whatever
|- myapp/
| \- __init__.py (etc.)
\- run (a #!/usr/bin/env python script including "import myapp")
Installed:
/usr/bin/myapp
\- myapp -> /usr/share/myapp/run (symlink)
/usr/share/myapp
|- myapp/
| \- __init__.py (etc.)
\- run
When developing, you run "./run --args", and Python puts the equivalent
of $(pwd) on sys.path, and uses $(pwd)/myapp for "import myapp".
When installed, you run "myapp --args" and Python follows the symlink,
finds /usr/share/myapp/run, puts /usr/share/myapp on sys.path, and uses
/usr/share/myapp/myapp for "import myapp".
S
Reply to: