False positive mismatch in dependencies

[djetelina]

I'm fairly sure the installed version of requests should go through no problem:

Adding docker-compose to Pipfile's [dev-packages]…
Locking [dev-packages] dependencies…
Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
  You can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
Could not find a version that matches requests!=2.11.0,<2.12,==2.18.4,>=2.6.1
Tried: 0.2.0, 0.2.1, 0.2.2, 0.2.3, 0.2.4, 0.3.0, 0.3.1, 0.3.2, 0.3.3, 0.3.4, 0.4.0, 0.4.1, 0.5.0, 0.5.1, 0.6.0, 0.6.1, 0.6.2, 0.6.3, 0.6.4, 0.6.5, 0.6.6, 0.7.0, 0.7.1, 0.7.2, 0.7.3, 0.7.4, 0.7.5, 0.7.6, 0.8.0, 0.8.1, 0.8.2, 0.8.3, 0.8.4, 0.8.5, 0.8.6, 0.8.7, 0.8.8, 0.8.9, 0.9.0, 0.9.1, 0.9.2, 0.9.3, 0.10.0, 0.10.1, 0.10.2, 0.10.3, 0.10.4, 0.10.6, 0.10.7, 0.10.8, 0.11.1, 0.11.2, 0.12.0, 0.12.1, 0.13.0, 0.13.1, 0.13.2, 0.13.3, 0.13.4, 0.13.5, 0.13.6, 0.13.7, 0.13.8, 0.13.9, 0.14.0, 0.14.1, 0.14.2, 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.0.4, 1.1.0, 1.2.0, 1.2.1, 1.2.2, 1.2.3, 2.0.0, 2.0.0, 2.0.1, 2.0.1, 2.1.0, 2.1.0, 2.2.0, 2.2.0, 2.2.1, 2.2.1, 2.3.0, 2.3.0, 2.4.0, 2.4.0, 2.4.1, 2.4.1, 2.4.2, 2.4.2, 2.4.3, 2.4.3, 2.5.0, 2.5.0, 2.5.1, 2.5.1, 2.5.2, 2.5.2, 2.5.3, 2.5.3, 2.6.0, 2.6.0, 2.6.1, 2.6.1, 2.6.2, 2.6.2, 2.7.0, 2.7.0, 2.8.0, 2.8.0, 2.8.1, 2.8.1, 2.9.0, 2.9.0, 2.9.1, 2.9.1, 2.9.2, 2.9.2, 2.10.0, 2.10.0, 2.11.0, 2.11.0, 2.11.1, 2.11.1, 2.12.0, 2.12.0, 2.12.1, 2.12.1, 2.12.2, 2.12.2, 2.12.3, 2.12.3, 2.12.4, 2.12.4, 2.12.5, 2.12.5, 2.13.0, 2.13.0, 2.14.0, 2.14.0, 2.14.1, 2.14.1, 2.14.2, 2.14.2, 2.15.1, 2.15.1, 2.16.0, 2.16.0, 2.16.1, 2.16.1, 2.16.2, 2.16.2, 2.16.3, 2.16.3, 2.16.4, 2.16.4, 2.16.5, 2.16.5, 2.17.0, 2.17.0, 2.17.1, 2.17.1, 2.17.2, 2.17.2, 2.17.3, 2.17.3, 2.18.0, 2.18.0, 2.18.1, 2.18.1, 2.18.2, 2.18.2, 2.18.3, 2.18.3, 2.18.4, 2.18.4

 > pipenv graph
docker-compose==1.16.0
  - cached-property [required: >=1.2.0,<2, installed: 1.3.1]
  - docker [required: <3.0,>=2.5.1, installed: 2.6.1]
    - docker-pycreds [required: >=0.2.1, installed: 0.2.1]
      - six [required: >=1.4.0, installed: 1.11.0]
    - requests [required: !=2.11.0,!=2.12.2,!=2.18.0,>=2.5.2, installed: 2.11.1]
    - six [required: >=1.4.0, installed: 1.11.0]
    - websocket-client [required: >=0.32.0, installed: 0.44.0]
      - six [required: Any, installed: 1.11.0]
  - dockerpty [required: <0.5,>=0.4.1, installed: 0.4.1]
    - six [required: >=1.3.0, installed: 1.11.0]
  - docopt [required: <0.7,>=0.6.1, installed: 0.6.2]
  - jsonschema [required: >=2.5.1,<3, installed: 2.6.0]
  - PyYAML [required: <4,>=3.10, installed: 3.12]
  - requests [required: !=2.11.0,<2.12,>=2.6.1, installed: 2.11.1]
  - six [required: >=1.3.0,<2, installed: 1.11.0]
  - texttable [required: >=0.9.0,<0.10, installed: 0.9.1]
  - websocket-client [required: <1.0,>=0.32.0, installed: 0.44.0]
    - six [required: Any, installed: 1.11.0]
setproctitle==1.1.10

Describe your environment

Ubuntu 17.04, python 3.5.3 inside of pipenv, pipenv 8.3.1

Expected result

I'd expect the lock to suceed with requests 2.11.1

Actual result

Dependencies are unresolved

Steps to replicate

> pipenv install --three
> pipenv install docker-compose requests

doesn't happen with docker-compose alone

Pipfile under packages:

requests = "*"
docker-compose = "*"

[vphilippon]

Could not find a version that matches requests!=2.11.0,<2.12,==2.18.4,>=2.6.1

I believe this is the same issue as with #875, where the requests candidate is pinned too-early by pipenv, later creating a conflict with <2.12

@iScrE4m In order to confirm my suspicions, could you provide the output of
pipenv lock --clear --verbose?

[techalchemy]

@iScrE4m @vphilippon Note also that pipenv graph kind of implies a solution to this problem by telling you that requests is a dependency of docker-compose. The fact that it is not a top-level package means you should let it be installed by the things that depend on it (in this case, docker-compose). So the solution here is to just remove it from your pipfile and the problem is solved.

[djetelina]

@techalchemy I fixed it that way for now, but it still sucks a lot. One day we might not need docker-compose in the pipfile anymore and with removal, everything will start crashing because of no requests.

@vphilippon Output of lock --clear--verbose:

Locking [dev-packages] dependencies…
Using pip: -i https://pypi.python.org/simple

                          ROUND 1                           
Current constraints:

Finding the best candidates:

Finding secondary dependencies:
------------------------------------------------------------
Result of round 1: stable, done
Locking [packages] dependencies…
Using pip: -i https://pypi.python.org/simple

                          ROUND 1                           
Current constraints:
  docker-compose
  requests

Finding the best candidates:
  found candidate docker-compose==1.17.1 (constraint was <any>)
  found candidate requests==2.18.4 (constraint was <any>)

Finding secondary dependencies:
  docker-compose==1.17.1 not in cache, need to check index
  docker-compose==1.17.1    requires cached-property<2,>=1.2.0, docker-compose==1.17.1, docker<3.0,>=2.5.1, dockerpty<0.5,>=0.4.1, docopt<0.7,>=0.6.1, jsonschema<3,>=2.5.1, PyYAML<4,>=3.10, requests!=2.11.0,<2.12,>=2.6.1, six<2,>=1.3.0, texttable<0.10,>=0.9.0, websocket-client<1.0,>=0.32.0
  requests==2.18.4 not in cache, need to check index
  requests==2.18.4          requires certifi>=2017.4.17, chardet<3.1.0,>=3.0.2, idna<2.7,>=2.5, requests==2.18.4, urllib3<1.23,>=1.21.1

New dependencies found in this round:
  adding ['cached-property', '<2,>=1.2.0', '[]']
  adding ['certifi', '>=2017.4.17', '[]']
  adding ['chardet', '<3.1.0,>=3.0.2', '[]']
  adding ['docker', '<3.0,>=2.5.1', '[]']
  adding ['docker-compose', '==1.17.1', '[]']
  adding ['dockerpty', '<0.5,>=0.4.1', '[]']
  adding ['docopt', '<0.7,>=0.6.1', '[]']
  adding ['idna', '<2.7,>=2.5', '[]']
  adding ['jsonschema', '<3,>=2.5.1', '[]']
  adding ['pyyaml', '<4,>=3.10', '[]']
  adding ['requests', '!=2.11.0,<2.12,==2.18.4,>=2.6.1', '[]']
  adding ['six', '<2,>=1.3.0', '[]']
  adding ['texttable', '<0.10,>=0.9.0', '[]']
  adding ['urllib3', '<1.23,>=1.21.1', '[]']
  adding ['websocket-client', '<1.0,>=0.32.0', '[]']
Removed dependencies in this round:
Unsafe dependencies in this round:
------------------------------------------------------------
Result of round 1: not stable

                          ROUND 2                           
Current constraints:
  cached-property<2,>=1.2.0
  certifi>=2017.4.17
  chardet<3.1.0,>=3.0.2
  docker<3.0,>=2.5.1
  docker-compose==1.17.1
  dockerpty<0.5,>=0.4.1
  docopt<0.7,>=0.6.1
  idna<2.7,>=2.5
  jsonschema<3,>=2.5.1
  PyYAML<4,>=3.10
  requests!=2.11.0,<2.12,==2.18.4,>=2.6.1
  six<2,>=1.3.0
  texttable<0.10,>=0.9.0
  urllib3<1.23,>=1.21.1
  websocket-client<1.0,>=0.32.0

Finding the best candidates:
  found candidate cached-property==1.3.1 (constraint was >=1.2.0,<2)
  found candidate certifi==2017.11.5 (constraint was >=2017.4.17)
  found candidate chardet==3.0.4 (constraint was >=3.0.2,<3.1.0)
  found candidate docker==2.6.1 (constraint was >=2.5.1,<3.0)
  found candidate docker-compose==1.17.1 (constraint was ==1.17.1)
  found candidate dockerpty==0.4.1 (constraint was >=0.4.1,<0.5)
  found candidate docopt==0.6.2 (constraint was >=0.6.1,<0.7)
  found candidate idna==2.6 (constraint was >=2.5,<2.7)
  found candidate jsonschema==2.6.0 (constraint was >=2.5.1,<3)
  found candidate pyyaml==3.12 (constraint was >=3.10,<4)
Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
  You can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
Could not find a version that matches requests!=2.11.0,<2.12,==2.18.4,>=2.6.1
Tried: 0.2.0, 0.2.1, 0.2.2, 0.2.3, 0.2.4, 0.3.0, 0.3.1, 0.3.2, 0.3.3, 0.3.4, 0.4.0, 0.4.1, 0.5.0, 0.5.1, 0.6.0, 0.6.1, 0.6.2, 0.6.3, 0.6.4, 0.6.5, 0.6.6, 0.7.0, 0.7.1, 0.7.2, 0.7.3, 0.7.4, 0.7.5, 0.7.6, 0.8.0, 0.8.1, 0.8.2, 0.8.3, 0.8.4, 0.8.5, 0.8.6, 0.8.7, 0.8.8, 0.8.9, 0.9.0, 0.9.1, 0.9.2, 0.9.3, 0.10.0, 0.10.1, 0.10.2, 0.10.3, 0.10.4, 0.10.6, 0.10.7, 0.10.8, 0.11.1, 0.11.2, 0.12.0, 0.12.1, 0.13.0, 0.13.1, 0.13.2, 0.13.3, 0.13.4, 0.13.5, 0.13.6, 0.13.7, 0.13.8, 0.13.9, 0.14.0, 0.14.1, 0.14.2, 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.0.4, 1.1.0, 1.2.0, 1.2.1, 1.2.2, 1.2.3, 2.0.0, 2.0.0, 2.0.1, 2.0.1, 2.1.0, 2.1.0, 2.2.0, 2.2.0, 2.2.1, 2.2.1, 2.3.0, 2.3.0, 2.4.0, 2.4.0, 2.4.1, 2.4.1, 2.4.2, 2.4.2, 2.4.3, 2.4.3, 2.5.0, 2.5.0, 2.5.1, 2.5.1, 2.5.2, 2.5.2, 2.5.3, 2.5.3, 2.6.0, 2.6.0, 2.6.1, 2.6.1, 2.6.2, 2.6.2, 2.7.0, 2.7.0, 2.8.0, 2.8.0, 2.8.1, 2.8.1, 2.9.0, 2.9.0, 2.9.1, 2.9.1, 2.9.2, 2.9.2, 2.10.0, 2.10.0, 2.11.0, 2.11.0, 2.11.1, 2.11.1, 2.12.0, 2.12.0, 2.12.1, 2.12.1, 2.12.2, 2.12.2, 2.12.3, 2.12.3, 2.12.4, 2.12.4, 2.12.5, 2.12.5, 2.13.0, 2.13.0, 2.14.0, 2.14.0, 2.14.1, 2.14.1, 2.14.2, 2.14.2, 2.15.1, 2.15.1, 2.16.0, 2.16.0, 2.16.1, 2.16.1, 2.16.2, 2.16.2, 2.16.3, 2.16.3, 2.16.4, 2.16.4, 2.16.5, 2.16.5, 2.17.0, 2.17.0, 2.17.1, 2.17.1, 2.17.2, 2.17.2, 2.17.3, 2.17.3, 2.18.0, 2.18.0, 2.18.1, 2.18.1, 2.18.2, 2.18.2, 2.18.3, 2.18.3, 2.18.4, 2.18.4

[kennethreitz]

uh that doesn't look like it'd resolve to me

[vphilippon]

@kennethreiz I have no issue resolving this with pip-tools. I'm pretty sure it's related to the issue I want to fix with my opened PR

[kennethreitz]

how can <2.12,==2.18.4 ever resolve?

[nateprewitt]

The only requirement is <2.12. Our modified version of pip-tools is forcing the most current version of a package as a pin on the first round of resolution which isn't correct.

[vphilippon]

Because ==2.18.4 is a false pin introduced by pipenv. Look how early it's added, that's on the selection of the first candidate.

[vphilippon]

What Nate said

[kennethreitz]

gotcha

…

On Tue, Nov 21, 2017 at 8:02 PM, Vincent Philippon ***@***.*** > wrote: What Nate said — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <https://github.com/kennethreitz/pipenv/issues/1060#issuecomment-346210554>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHUVQXgYXPzdBL1Xgg2hgjnH513SCJ2ks5s43KVgaJpZM4QcEGu> .

[vphilippon]

@iScrE4m This is now fixed in master and will be part of the next release, hopefully in the next few days (cutting out a major version).
Once it's out (or using the version on master), be sure to run pipenv lock --clear.

Thank you for your report, patience, and using Pipenv! 👍