Pipenv ignores conflicts between default and development dependencies

Describe your environment

1. OS Type: OS X
2. Python version: Python 3.6.3
3. Pipenv version: pipenv, version 8.3.1

Expected result

Suppose I have a default dependency that depends on six==1.10.0 and a development dependency that depends on six==1.11.0.

I expect to get some sort of error here, because it’s impossible to satisfy both transitive requirements simultaneously.

Actual result

$ pipenv graph
dep-bar==0.0.0
  - six [required: ==1.11.0, installed: 1.10.0]
dep-foo==0.0.0
  - six [required: ==1.10.0, installed: 1.10.0]

Pipfile.lock is great, too, featuring:

    "default": {
        "dep-foo": {
            "editable": true,
            "git": "[e-mail]:taion/dep_foo.git"
        },
        "six": {
            "hashes": [
                "sha256:0ff78c403d9bccf5a425a6d31a12aa6b47f1c21ca4dc2573a7e2f32a97335eb1",
                "sha256:105f8d68616f8248e24bf0e9372ef04d3cc10104f1980f54d57b2ce73a5ad56a"
            ],
            "version": "==1.10.0"
        }
    },
    "develop": {
        "dep-bar": {
            "editable": true,
            "git": "[e-mail]:taion/dep_bar.git"
        },
        "six": {
            "hashes": [
                "sha256:832dc0e10feb1aa2c68dcc57dbb658f1c7e65b9b61af69048abc87a2db00a0eb",
                "sha256:70e8a77beed4562e7f14fe23a786b54f6296e34344c23bc42f07b15018ff98e9"
            ],
            "version": "==1.11.0"
        }
    }

Steps to replicate

[[source]]

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


[packages]

dep_foo = {git = "[e-mail]:taion/dep_foo.git", editable = true}


[dev-packages]

dep_bar = {git = "[e-mail]:taion/dep_bar.git", editable = true}

[audiolion]

Thanks for the reads @kennethreitz , I think if people read these it will help them empathize with your situation. I won’t deny that I have been frustrated by the terse responses or the closed issues with no comments before, but I also know that you are doing this with your own free time and have so much going on so when I consider that it is easy to quell those feelings and try to be respectful as possible.

Pipenv has started to be recommended as the tool to use and has come under higher scrutiny as a result. When things break between minor releases, when easter eggs cause crashes, when things break unexpectedly due to Pipfile lock resolution issues, it culminate in a lot of pressure due to the expectation that this is a product designed for everyone to use and should be the standard. I believe this is the source of frustration for many people who are spending many hours moving projects over to pipenv and updating docs and workflows for pipenv, to then run into showstopping bugs that are met with the aforementioned terse responses and closed issues. This signals to me at least that the product is not ready yet due to lack of resources and support and thus should not be advocated so highly until such time as it is ready.

[jsatt]

This is biting me this morning with Django 2.0 being released over the weekend.

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

[requires]
python_version = "2.7"

[dev-packages]
django-debug-toolbar = "==1.9.1"

[packages]
django = "==1.8.18"

Since debug toolbar has a requirement of “django>=1.8” it separately matches “django==2.0” which of course causes a problem on Python 2.7. If pipenv install --dev is going to always respect the merged result of packages and dev-packages dependencies, I think that locking should as well.

For others hitting this, my workaround for now is add django = "<2" to dev-packages.

Edit: Error I was getting is Command "python setup.py egg_info" failed with error code 1 in /tmp/tmplI41p5build/Django/. Hopefully that makes this issue more Google-able.