-
-
Notifications
You must be signed in to change notification settings - Fork 30.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
py.exe launcher ignores [commands] from py.ini #100247
Comments
Thinking about it some more, I question whether the call to [commands]
something/apython=C:\something\a\python.exe
/usr/bin/something/apython=C:\something\b\python.exe a script with shebang line (However it seems that this has already worked this way in the 3.9 and 3.10 launcher.) |
I think what probably needs to happen here (writing my logic down so I can double check once this headache is over) is that the templates should require I agree that the original PEP suggests the custom command should be checked first taking the entire first argument from the shebang, but as pointed out, that's not how it worked in the past. Implementation wins over the original propsal here (since the docs don't even mention this feature). |
… for finding custom commands.
… for finding custom commands (pythonGH-100944) (cherry picked from commit 468c3bf) Co-authored-by: Steve Dower <steve.dower@python.org>
Thanks! I’ll give it a test when I’m back at my work Windows desktop, probably some time next week. This bit worries me a little, though:
If that is true, then there may still be a regression compared to 3.11.0. The actual example we are using in our shipping product to make sure our scripts launch with our own Python installations on both Linux and Windows (which worked with the 3.9 launcher we ship but broke when users installed a 3.11.1 launcher) is
with py.ini
where on Linux /opt/indel/bin/indel-python* are symlinks to the appropriate interpreter while the Windows paths are the actual installation locations. (I’m not 100% certain we really need the |
Those are all fine. What it means is that you can't use Also, you can't use |
Ah, OK. That makes sense. “name of the command” refers to the the py.ini entry, not to the shebang line. |
… py.exe launcher (pythonGH-101083) (cherry picked from commit 30753c3) Co-authored-by: Steve Dower <steve.dower@python.org>
I have tested it now and it works perfectly for our purposes. Thanks again! It even fixes the paradoxical behavior I mentioned in #100247 (comment), which makes me happy. |
Bug report
This is a regression between Python 3.11.0 and 3.11.1. Since 46a3cf4 (88297e2, #98692), py.exe no longer observes the “custom commands” mapping under
[commands]
in py.ini defining additional “virtual commands” (unless the virtual command starts with the same prefix as one of the four predefined virtual commands), but directly tries to launch the virtual command as an executable.Steps to reproduce:
%WINDIR%\py.ini:
test.py:
Expected result (and actual up to 3.11.0):
Actual result:
I seem to be able to fix this as follows, which satisfies the existing tests, however this code is such a complex tangle of special cases that I have no idea whether it is the right thing to do. (The idea is that the loop over
shebangTemplates
should always find exactly one match, which was previously (before the regression) ensured by the empty template, so that_findCommand()
is always called. Checking fortmpl != &shebangTemplates[0]
is needed to satisfytest_recursive_search_path
, however it might exclude too much – maybesearchPath()
should instead report explicitly that it skipped a recursive call.)Your environment
Linked PRs
The text was updated successfully, but these errors were encountered: