This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: [feature] runpy.run_module should mimic script launch behavior for sys.path
Type: enhancement Stage:
Components: Library (Lib) Versions: Python 3.7
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: jaraco, ncoghlan
Priority: normal Keywords:

Created on 2017-10-26 14:01 by jaraco, last changed 2022-04-11 14:58 by admin.

Messages (4)
msg305054 - (view) Author: Jason R. Coombs (jaraco) * (Python committer) Date: 2017-10-26 14:01
In [this comment](https://bugs.python.org/issue16737#msg282872) I describe an issue whereby launching an application via runpy.run_module (aka python -m) produces different and unexpected behavior than running the same app via an entry script.

In [this followup comment](https://bugs.python.org/issue16737#msg304662), I provide more detail on why a user might expect for run_module to mimic the behavior of launching a script.

[Nick suggests](https://bugs.python.org/issue16737#msg304707):

> Update sys.path[0] based on __main__.__spec__.origin after [resolving] __main__.__spec__. That way it will only stay as the current directory if the module being executed is in a subdirectory of the current directory, and will otherwise be updated appropriately for wherever we actually found the main module.
msg305057 - (view) Author: Jason R. Coombs (jaraco) * (Python committer) Date: 2017-10-26 14:07
At first, I didn't understand why one wouldn't simply omit sys.path[0], similar to what scripts do, but then I realized that Nick was aware of a common use-case that I was overlooking - that `python -m` may be used to launch behavior in a local package - in which case it's relevant and important that sys.path[0] == ''.
msg323419 - (view) Author: Jason R. Coombs (jaraco) * (Python committer) Date: 2018-08-11 17:39
In [setuptools 1453](https://github.com/pypa/setuptools/issues/1453), this issue hit the project hard. Tox 3.2 changed the default invocation of pip from the script-based invocation to the runpy based implementation (python -m pip), which causes pip to be unable to uninstall the setuptools in the environment.

This use case also reveals that the heuristic of "retain '' in sys.path if the module being executed is in a subdirectory of a current directory" wouldn't address the issue, as `.tox/python/lib/python3.7/site-packages/pip/__main__.py` is in a subdirectory of the current directory, but one would still expect '' not to be in sys.path in this case.

But basing on __main__.__spec__, that would probably do what is expected.
msg351070 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2019-09-03 07:47
Good point regarding the heuristic: it would need to take the requested module name into account to be correct.

* check if the requested module was found relative to the current directory (can be worked out from __main__.__spec__ and the current working directory)
* if it was, make sys.path[0] the absolute path of the current directory
* otherwise, remove sys.path[0] entirely
History
Date User Action Args
2022-04-11 14:58:53adminsetgithub: 76055
2019-09-03 07:47:43ncoghlansetnosy: + ncoghlan
messages: + msg351070
2018-08-11 17:39:18jaracosetmessages: + msg323419
2017-10-26 14:07:58jaracosetcomponents: + Library (Lib)
2017-10-26 14:07:47jaracosettype: enhancement
2017-10-26 14:07:12jaracosetmessages: + msg305057
2017-10-26 14:01:14jaracocreate