|
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/envThat 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
[Prev in Thread] | Current Thread | [Next in Thread] |