Clarify that `--deploy` is meant for enforcement and intentionally
failing a build.
Mention `pipenv sync` in the same section to try to establish it more
clearly as the most obvious and normal way of doing installation from
``Pipfile.lock`` as part of a reproducible build process.
Explicitly recommend against `pipenv install --ignore-pipfile` and
suggest that it may be deprecated.
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.
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
I believe `passenv=HOME` is no (or no longer?) necessary, as pipenv will
use the virtualenv it is running in. In addition this adds a
recommendation to add `--ignore-pipfile` to `pipenv install`, to protect
the locked dependency set from accidental changes.
frostming
kennethreitz