By default, `pipenv install` will install packages
based on the list in `Pipfile`, not `Pipfile.lock`.
`pipenv install --dev` is no exception.
I've tested this using pipenv 2018.7.1
with different package versions in `Pipfile`
and `Pipfile.lock`. After `pipenv install`,
the versions in `Pipfile` were the ones
actually installed.
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.
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.
Dan Ryan
kennethreitz