gpsd-dev
[Top][All Lists]
Advanced

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

Re: ✘python shebang, yet again


From: Fred Wright
Subject: Re: ✘python shebang, yet again
Date: Thu, 24 Sep 2020 19:50:36 -0700 (PDT)
User-agent: Alpine 2.23 (OSX 453 2020-06-18)


On Thu, 24 Sep 2020, Greg Troxel wrote:
"Gary E. Miller" <gem@rellim.com> writes:

I could live with removing /usr/bin/env IFF target_python is a full
path.  Otherwise keep the /usr/bin/env

That is probably the best thing in terms of making the most people
happy.  If people want to set target_python to not a full path, which I
understand many do, then they do need env.  But for those who pass a full
path, I think essentially all of them just want that executed.

Currently, target_python can be anything that launches a Python interepreter, i.e.:

1) A "command" evaluated in the context of PATH.
2) An absolute path.
3) A relative path (though this would be pretty weird).

It wouldn't be a disaster if #3 didn't work at all, although I think there's a fairly straightforward way to handle all three:

1) If target_python doesn't contain os.path.sep at all, then consider it to be a "command", and prefix it with "/usr/bin/env " in the default shebang.

2) If it starts with os.path.sep, then consider it to be an absolute path, and use it as is without the "/usr/bin/env". I believe including "/usr/bin/env" in this context is actually a NOP, but it's pretty silly.

3) Otherwise (i.e. it contains os.path.sep but doesn't start with it), then consider it to be a relative path. Convert it to an absolute path and use it as in #2.

(The point of using a full path is to bind to a particular python build
at gpsd configure/build time, rather than having it end up using one at
runtime that may or may not have been changed.  But I've said that
before, and the PEP people don't value that property.)

Remember that PEP 394 was written to address the specific issue of Python 2 vs. Python 3 and programs that would only work with one, and didn't consider such issues as third-party libraries and their locations at all. Nevertheless, it does state that more specific versioning is preferable to less specific versioning, so if one considers the full absolute path to the Python interpreter as the most specfic versioning of all, then that should actually be considered ideal by PEP 394. :-)

Using the absolute path is the most robust approach, since it defends against future changes to PATH and/or the symlink that something like 'python3' probably refers to. There's an enhancement I've used in another context to make this more convenient, where prefixing the target_python argument with '@' causes it to use the target python's sys.executable for the shebang. That way one can just say something like "target_python=@python3", and have it bound to the specific Python 3 used at the time of the install. Packaging systems, of course, would normally be more specfic, anyway.

Fred Wright



reply via email to

[Prev in Thread] Current Thread [Next in Thread]