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.
We removed the embedded copy of Safety-DB, so there's
no longer any copyright concern about the CC-BY-NC-SA
license, but it does mean `pipenv check` may end up throttled
eventually as all requests to the backend API use a common
key.
Jannis Gebauer of pyup.io let us know that he's definitely fine
with commercial *use* of the `pipenv check` feature, so it's
only commercial redistributors of `pipenv` that may need to
take a closer look at the licensing situation, and perhaps
talk to `pyup.io` directly.
Follow-up to #1651
Dan Ryan
kennethreitz