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.
Removed ppa mentions from documentation, and re-organised the page a bit
to make it structurally easier to upderstand.
Both the documentation's front page and README.rst now actively refer to
the page so user can be directed to better installation methods. (I
don't think this is very useful TBT because people don't use manuals,
but we should still do it.)
Also fixed many Sphinx warnings during documentation builds.
Adds support for the --pypi-mirror command line parameter and the
PIPENV_PYPI_MIRROR environment variable for most pipenv operations.
This permits pipenv to function without pypi.org, which is necessary for
users:
1. behind restrictive networks
2. facing strict artifact sourcing policies
3. experiencing poor performance connecting to pypi.org
4. who've configured a local cache for performance reasons
When specified, the value of this parameter replaces all instances of
pypi.org and pypi.python.org within pipenv operations without modifying
or requring the modification of Pipfiles.
- Resolves#2075
Tzu-ping Chung
kennethreitz