Pipenv: Installing packges from requirements.txt complains about require-hashes and some packages not having their versions pinned

[c-garcia]

pip install -r requirements.txt using the file generated by pipenv lock -r complains about some packages not having their version pinned with ==. Among them, setuptools and six.

It may be related to #1417

Describe your environment

1. OS Type: MacOS 10.12.6 (with MacPorts)
2. Python version: 3.6.4
3. Pipenv version: 9.1.0 (installed from master, on Feb, 18th)

Expected result

I expected the all packages being installed in the target directory with versions coherent with Pipfile.lock

Actual result

In --require-hashes mode, all requirements must have their versions pinned with ==. These do not:
    setuptools>=0.6b1 from https://pypi.python.org/packages/43/41/033a273f9a25cb63050a390ee8397acbc7eae2159195d85f06f17e7be45a/setuptools-38.5.1-py2.py3-none-any.whl#md5=908b8b5e50bf429e520b2b5fa1b350e5 (from injector==0.13.4->-r target/requirements.txt (line 5))
    six from https://pypi.python.org/packages/67/4b/141a581104b1f6397bfa78ac9d43d8ad29a7ca43ea90a2d863fe3056e86a/six-1.11.0-py2.py3-none-any.whl#md5=866ab722be6bdfed6830f3179af65468 (from purl==1.3.1->-r target/requirements.txt (line 6))

Steps to replicate

With this Pipfile

[[source]]

url = "https://pypi.python.org/simple"
verify_ssl = true
name = "pypi"


[packages]

purl = "*"
requests = "*"
python-dotenv = "*"
injector = "*"
voluptuous = "*"


[dev-packages]

"boto3" = "*"
pytest = "*"
pytest-mock = "*"
selenium = "*"
bpython = "*"

Commands

mkdir target
pipenv lock -r > target/requirements.txt
# with pip executed from a shell created with pipenv shell or from a new one
pip install -r target/requirements.txt -t target

[dewe]

Same here. In my case, there is a line in the requirements.txt that starts with #, quite suspicious.

bugsnag==3.4.0 --hash=sha256:07e4cce9aad5a41b9c21410102cfd4bc635e93facf2162746a6cda3d61e35ba3  --hash=sha256:5f7d20fe37183030b42570c2e5206949f3bae9fbe5f4fdbbe709d963d9666c9d  --hash=sha256:7fc68389bc1fb02ab77e1a65a1b4e21fd3cce752d44ed6c418a6bdc1dc1ab89f
certifi==2018.1.18 --hash=sha256:14131608ad2fd56836d33a71ee60fa1c82bc9d2c8d98b7bdbc631fe1b3cd1296  --hash=sha256:edbc3f203427eef571f79a7692bb160a2b0f7ccaa31953e99bd17e307cf63f7d
chardet==3.0.4 --hash=sha256:fc323ffcaeaed0e0a02bf4d117757b98aed530d9ed4531e3e15460124c106691  --hash=sha256:84ab92ed1c4d4f16916e05906b6b75a6c0fb5db821cc65e70cbd64a3e2a5eaae
idna==2.6 --hash=sha256:8c7309c718f94b3a625cb648ace320157ad16ff131ae0af362c9f21b80ef6ec4  --hash=sha256:2c6a5de3089009e3da7c5dde64a141dbc8551d5b7f6cf4ed7c2568d0cc520a8f
pymysql==0.8.0 --hash=sha256:04fa19fad017fdb21394fad2878c1d6bd346959d4fbfd1b66050a09fc636a321  --hash=sha256:32da4a66397077d42908e449688f2ec71c2b18892a6cd04f03ab2aa828a70f40
requests==2.18.4 --hash=sha256:6a1b267aa90cac58ac3a765d067950e7dbbf75b1da07e895d1f594193a40a38b  --hash=sha256:9c443e7324ba5b85070c4a818ade28bfabedf16ea10206da1132edaa6dda237e
# six==1.11.0 --hash=sha256:832dc0e10feb1aa2c68dcc57dbb658f1c7e65b9b61af69048abc87a2db00a0eb  --hash=sha256:70e8a77beed4562e7f14fe23a786b54f6296e34344c23bc42f07b15018ff98e9
urllib3==1.22 --hash=sha256:06330f386d6e4b195fbfc736b297f58c5a892e4440e54d294d7004e3a9bbea1b  --hash=sha256:cc44da8e1145637334317feebd728bd869a35285b93cbb4cca2577da7e62db4f
webob==1.7.4 --hash=sha256:63f4220492476c5c716b615baed7bf3d27040b3105014375787160dee0943115  --hash=sha256:8d10af182fda4b92193113ee1edeb687ab9dc44336b37d6804e413f0240d40d9

Edit: might be intentional. See https://github.com/pypa/pipenv/blob/9f41427a678e816538cec891f2e655e05a7eaad3/HISTORY.txt#L5

[dewe]

Btw, if there was an option for having pipenv install installing to a specific folder I would not be using pipenv lock -r.

[gifflen]

Happening to me as well. We do builds in containers and ship in a requirements file as the builder doesn't respect pipfile yet. This change broke our build workflows pretty much across the board since just about everything in the world seems to have six as a dependency somewhere

[jtratner]

Aside - it’s a little hacky, but you can construct your own virtualenv,
source that and then use pipenv to install there (thereby getting custom
output folder) or alternatively use --system or --python
On Tue, Feb 20, 2018 at 3:00 PM Bruce Stringer [e-mail]
wrote:

Happening to me as well. We do builds in containers and ship in a
requirements file as the builder doesn't respect pipenv yet. This change
broke our build workflows pretty much across the board since just about
everything in the world seems to have six as a dependency somewhere

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/pypa/pipenv/issues/1449#issuecomment-367151380, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABhjq0nYGOO2FNfguwDxCVflgLN00uBBks5tW06QgaJpZM4SJ4Fq
.

[jtratner]

(In response to “Btw, if there was an option for having pipenv install
installing to a specific folder I would not be using pipenv lock -r.”)
On Tue, Feb 20, 2018 at 3:03 PM Jeffrey Tratner [e-mail]
wrote:

Aside - it’s a little hacky, but you can construct your own virtualenv,
source that and then use pipenv to install there (thereby getting custom
output folder) or alternatively use --system or --python
On Tue, Feb 20, 2018 at 3:00 PM Bruce Stringer [e-mail]
wrote:

Happening to me as well. We do builds in containers and ship in a
requirements file as the builder doesn't respect pipenv yet. This change
broke our build workflows pretty much across the board since just about
everything in the world seems to have six as a dependency somewhere

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/pypa/pipenv/issues/1449#issuecomment-367151380, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABhjq0nYGOO2FNfguwDxCVflgLN00uBBks5tW06QgaJpZM4SJ4Fq
.

[techalchemy]

This seems like it needs to be addressed with some expedience. I haven't looked that carefully at the change but I assume if anyone can pinpoint and isolate the root that would help

[dewe]

Current workaround is to run Pipenv 9.0.3.

[gifflen]

@techalchemy It looks like it was introduced in this commit https://github.com/pypa/pipenv/commit/9f41427a678e816538cec891f2e655e05a7eaad3

I'm not familiar with the issue that kenneth was trying to work around here but I assume there as a good reason but it is causing issues as it changed expected behavior.

[kennethreitz42]

this should now be fixed