Small changes, but a couple of issues in the `A Note About VCS Dependencies` section of the docs.
Running the example `$ pipenv install -e git+https://github.com/requests/requests.git@v2.19#egg=requests` raises the error: `Did not find branch or tag 'v2.19', assuming revision or ref.` I think it should be 'v2.19.1' which is just a typo as 'v2.19.1' is used in the subsequent lines of the example.
The example Pipfile in the section excludes the `v` in the version number written to the `ref = ` part. I found it a little confusing that it would strip the 'v' from the tag, but then on testing it I found that it doesn't do that:
```
[packages]
requests = {editable = true, ref = "v2.20.1", git = "https://github.com/requests/requests.git"}
```
Also, while I was here I figured I'd update the example to the most recent requests release.
Thanks.
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.
Frost Ming
kennethreitz