In the Specifying Versions section of the Basics documentation, there is
a misleading code comment saying that requests~=1.2 is equivalent to
requests~=1.2.0, which it isn’t. ~=1.2 is equivalent to >=1.2,<2.0, but
~=1.2.0 is equivalent to >=1.2.0,<1.3. Fixed by removing the comment.
Previously it was confusing as to what `" "` meant exactly -- I read it
as a whitespace character was needed somewhere when it's referring to
the double quote characters.
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.
When importing from requirements.txt, it may be useful to
keep the versions of packages you have for the moment,
while unpinning them for the future. This is already supported
via `--keep-outdated`; this commit adds a mention to the docs.
Fixes#908.
Ashwin Ramaswami
kennethreitz