[issue19141] Windows Launcher fails to respect PATH
Vinay Sajip added the comment: Closing, as no activity following Mark's comment. -- resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19141 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19141] Windows Launcher fails to respect PATH
Mark Hammond added the comment: I am trying to draw attention to the situation where the script has no shebang line, and there is no other explicit configuration info for py.exe. In that case, the user should just type python scriptname.py - py.exe is for cases where just specifying python doesn't do the right thing. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19141 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19141] Windows Launcher fails to respect PATH
Changes by Ned Deily n...@acm.org: -- nosy: +vinay.sajip ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19141 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19141] Windows Launcher fails to respect PATH
Vinay Sajip added the comment: The current version of py.exe *does* do a PATH search for a shebang of #!/usr/bin/env python (see #17903). The whole *point* of py.exe is to invoke Pythons which are *not* available on the PATH. The behaviour of py.exe is as documented in PEP 397, other than the PATH-searching for /usr/bin/env python which is a more recent addition. People are supposed to put shebang lines in their scripts, else PEP 397 is not of much use to them. Scripts installed via setuptools/pip (e.g. into a virtualenv) have correct shebang lines prepended to them. Note that the environment variables and some py.ini settings are *alternative* ways of specifying intent. The choosing of 2.x vs. 3.x is also mentioned in the PEP and was suggested as the best default for the largest user population - that of 2.x users potentially transitioning to 3.x. Is there some deviation from PEP 397 (other than /usr/bin/env python - PATH search) that you are trying to draw attention to? Or is purely a documentation fix sufficient? Otherwise, I will be closing this as wontfix, as the basic behaviour was thrashed out when PEP 397 was discussed. -- nosy: +mhammond ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19141 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19141] Windows Launcher fails to respect PATH
Graham Wideman added the comment: Hi Vinay, thanks for commenting. And of course for your efforts on py.exe (and no doubt the debate process.) I am trying to draw attention to the situation where the script has no shebang line, and there is no other explicit configuration info for py.exe. (No py.ini file, no py.exe envt variables, no py.exe-specific command-line args). In that case, the next thing py.exe should check, in my view, is the user's PATH, where they may well have defined which python version they prefer (even if they are unaware of PEP 397 and Launcher). This rationale is parallel to the one in #17903 that you pointed to. Currently, py.exe ignores PATH in that case, and falls back to looking through all installed pythons and picking the latest 2.x if available. The choosing of 2.x vs. 3.x is also mentioned in the PEP The discussion of that issue would be illuminating, but I couldn't find it. Could you point to where this is mentioned in PEP-0397? Thanks again. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19141 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19141] Windows Launcher fails to respect PATH
New submission from Graham Wideman: Python Launcher for Windows provides some important value for Windows users, but its ability to invoke python versions not on the PATH is a problem. py.exe chooses a version of Python to invoke, in more or less this order of decreasing priority; it is the *last* one that occurs by default in a new install of python 3.3.x: 1. Shebang line in myscript.py 2. py.exe -n argument (n can be 2, 3, 3.2 etc). Launcher chooses the latest installed version so specified. 3. PY_PYTHON environment variable 4. py.ini in C:\WINDOWS or user's %LOCALAPPDATA% directory 5. Launcher hunts through registry for ALL previously installed pythons, and picks the latest version in the 2.x series. DEFAULT. The first issue to note is that, to my knowledge, the exact precedence order is not documented... it would greatly help if this were done. That said, the focus in this report is case 5, which as noted is the default behavior when python 3.3.2 is installed (and py.exe invoked with scripts having no launcher-aware shebang line). In case 5, py.exe completely ignores the PATH environment variable. So, whereas PATH is used to find py.exe, or when the user invokes 'python' on the command line, py.exe ignores PATH and launches a version of python that is not necessarily in the PATH. In case 2 where the user supplies a value for 'n', finding a non-PATH version of python is excusable on the basis that the user deliberately requests a version. However, in case 5, the user is not invoking py explicitly, and is not necessarily aware of py's algorithm for finding all installed versions. The user might reasonably expect that invoking a script or double clicking it would just invoke 'python' the same as the 'python' command, using PATH. In particular, if the user understands how PATH works (as reviewed in the docs here: http://docs.python.org/3/using/windows.html#finding-the-python-executable), then upon installing 3.3.x, he or she might explicitly *remove* python 2.x from PATH in the expectation that this will disable python 2.x. It is surprising and potentially harmful that py.exe does not abide by that choice. A potential improvement is to interpose an item '4.5' in the above list, in which py.exe looks for a version of python on the PATH before falling back to searching for latest 2.x python ever installed. (It is not clear that py.exe should *ever* fallback to just picking the latest 2.x in the registry (item 5). It is conceivable that a user may have configured one of those pythons to do something destructive or insecure on startup, and it will be a great surprise if py.exe randomly invokes it just because it has the highest version number.) -- components: Windows messages: 198812 nosy: gwideman priority: normal severity: normal status: open title: Windows Launcher fails to respect PATH type: behavior versions: Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19141 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
