Despite an application's Docker container not usually running other Python processes than the application itself, it still has a system Python whose packages should not necessarily be overwritten or upgraded by an application's choices.
For example, `python3-software-properties` in Ubuntu contains utilities
written in Python like `add-apt-repository` whose [use is widespread in
Dockerfiles](https://github.com/search?l=Dockerfile&q=%22add-apt-repository%22&type=Code).
By inadvertently applying an application's dependency onto the the container's Python, it is possible to:
- subtly break system-level software like these that is still present in the container image
- run into errors where that software is executed while extending the image with another Dockerfile
- run into errors when `docker run|exec ... COMMAND` is used to run another process inside the same container for debugging purposes
I realize this is not necessarily a likely use case, but we have seen
enough projects/tools vendoring `Requests` in fear of a conflict.
Very open on the wording and whether `system Python` is the correct term
to designate the global Python for that OS/container image.
Some Windows users are used to launch files without specifying a command,
e.g.::
> my-script.py
This works in the shell because Windows will automatically choose an
command based on file association, and with newer Python versions, the Py
Launcher (py.exe) automatically chooses the correct Python based on
shebang-parsing.
A similar syntax, unfortunately, does not currently work in Pipenv::
> pipenv run my-script.py
Since my-script.py will be treated as a real application by the subprocess
module.
This patch catch Windows error 193 during subprocess initialization, and
fall back to use COMSPEC (shell=True) when it happens, to provide better
support for this use case.
Dan Ryan