-
-
Notifications
You must be signed in to change notification settings - Fork 30k
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
No way to recover original argv with python -m #58416
Comments
I have a script which attempts to re-invoke itself using sys.argv, but it fails when run with "python -m package.module". The problem is that the handling of -m (via the runpy module) rewrites sys.argv as if it were run as "python package/module.py", but the two command lines are not equivalent: With -m the current directory is inserted at the head of sys.path, but without -m it's the directory containing module.py. The net effect is that the initial run of "python -m package.module" works as expected, but when it re-runs itself as "python package/module.py" the imports from module.py are effectively relative instead of absolute. One possible solution would be to provide an immutable sys.__argv__ (by analogy with sys.__stdout__ and friends). |
I agree this would be useful. It would be even more useful to have an __argv__ that includes all command-line flags given to Python, such as -Wi. |
This is closely related to PEP-395, since multiprocessing currently hits the same issue in trying to figure out the correct setting for sys.argv0. I quite like the sys.__argv__ idea for preserving the *exact* underlying command line (Alex Gaynor was recently asking for something similar to this). In the meantime, it should be possible to work around the problem by running the affected subprocess invocations (i.e. when __main__.__package__ exists and is not empty) with something like: launch_template = """
import runpy, sys
sys.argv[:] = {argv}
sys.path[:] = {path}
runpy._run_module_as_main({main})
"""
import sys, subprocess, os.path, __main__
main_base = os.path.basename(__main.__file__).splitext()[0]
main_ref = __main__.__package__ + "." + main_base
launch = launch_template.format(argv=sys.argv, path=sys.path, main=main_ref)
subprocess.call(launch, shell=True, executable=sys.executable)
Note: the above isn't tested code, since it's an approach that only occurred to me recently and I haven't had a chance to fully explore it myself. However, if it works, we could make use of it in 2.7 and 3.2 to fix multiprocessing's current misbehaviour on Windows. |
Instead of sys.__argv__, may I suggest sys.argv_original or somesuch. |
In framing a question for Raymond regarding his preference for avoiding the __argv__ name, I realised I agreed with him. My reasoning is that, when a Python process starts, sys.stdin is sys.__stdin__, sys.stdout is sys.__stdout__ and sys.stderr is sys.__stderr__. The dunder versions capture the original values as created by the interpreter initialisation, not the raw OS level file descriptors. The new attribute proposed here is different - it's not an immutable copy of the original value of sys.argv, it's a *different* sequence altogether. The analogy with the standard stream initial value capture created by the use of sys.__argv__ would actually be misleading rather than helpful. For the same reason, Raymond's specific argv_original suggestion doesn't really work for me. Alas, I can think of several other possible colours for that particular bikeshed (such as argv_os, argv_main, argv_raw, argv_platform, argv_executable) without having any particular good way of choosing between them. |
I agree. Maybe I may throw "full_argv" or "executable_argv" (i.e. to be used with exec([sys.executable] + sys.executable_arg)) in the air? |
For PEP-432, I'm proposing to expose this as sys._configuration.raw_argv |
I think sys.raw_argv would be as good. It's not really (not only) a |
I'm not seeing a good justification for doing anything more, though:
Elevating it to part of the language standard doesn't make sense, while exposing it as an implementation feature of the CPython initialisation process seems more reasonable. |
I expect it to be useful in the "launch (almost) the same command in the |
Antoine Pitrou wrote on Sun, Jan 13, 2013 at 10:19:20 +0000:
What about the "launch a different command with the same interpreter Perhaps it'll be cleaner to expose in state_argv ['python', '-E']; in |
My use case is the reloader or restarter. I've initially fallen foul of this when using the cherrypy reloader (which does an execv by building from sys.executable + sys.argv) but I also have web services running which I'd like to restart remotely by forcing them to execv themselves. It's trivial to retrieve the original command line from the Windows API, shlex.split it and pass it along to execv so this is hardly a showstopper. But it would be useful to have something equivalent built-in. |
A few updates here:
|
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: