Could not find a version that matches django==1.4,==1.8.4,>=1.3,>=1.4,>=1.5

[milin]

Describe the issue briefly here.

Steps to replicate

1. ...Have two top level dependencies that in turn have a single dependency but are pinned to different versions.
2. ...For e.g package A has django==1.4 pinned, and package B has django==1.8.7 pinned

Expected result

Should download all requirements.
...

Actual result

...

Could not find a version that matches django==1.4,==1.8.4,>=1.3,>=1.4,>=1.5
Tried: 1.1.2, 1.1.3, 1.1.4, 1.2, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.2.6, 1.2.7, 1.3, 1.3.1, 1.3.2, 1.3.3, 1.3.4, 1.3.5, 1.3.6, 1.3.7, 1.4, 1.4.1, 1.4.2, 1.4
.3, 1.4.4, 1.4.5, 1.4.6, 1.4.7, 1.4.8, 1.4.9, 1.4.10, 1.4.11, 1.4.12, 1.4.13, 1.4.14, 1.4.15, 1.4.16, 1.4.17, 1.4.18, 1.4.19, 1.4.20, 1.4.21, 1.4.22, 1.5, 1.5
.1, 1.5.2, 1.5.2, 1.5.3, 1.5.4, 1.5.5, 1.5.6, 1.5.7, 1.5.8, 1.5.8, 1.5.9, 1.5.10, 1.5.11, 1.5.12, 1.5.12, 1.6, 1.6, 1.6.1, 1.6.1, 1.6.2, 1.6.2, 1.6.3, 1.6.3,
1.6.4, 1.6.4, 1.6.5, 1.6.5, 1.6.6, 1.6.6, 1.6.7, 1.6.7, 1.6.8, 1.6.8, 1.6.9, 1.6.9, 1.6.10, 1.6.10, 1.6.11, 1.6.11, 1.7, 1.7, 1.7.1, 1.7.1, 1.7.2, 1.7.2, 1.7.
3, 1.7.3, 1.7.4, 1.7.4, 1.7.5, 1.7.5, 1.7.6, 1.7.6, 1.7.7, 1.7.7, 1.7.8, 1.7.8, 1.7.9, 1.7.9, 1.7.10, 1.7.10, 1.7.11, 1.7.11, 1.8a1, 1.8b1, 1.8b2, 1.8rc1, 1.8
, 1.8, 1.8.1, 1.8.1, 1.8.2, 1.8.2, 1.8.3, 1.8.3, 1.8.4, 1.8.4, 1.8.5, 1.8.5, 1.8.6, 1.8.6, 1.8.7, 1.8.7, 1.8.8, 1.8.8, 1.8.9, 1.8.9, 1.8.10, 1.8.10, 1.8.11, 1
.8.11, 1.8.12, 1.8.12, 1.9a1, 1.9b1, 1.9rc1, 1.9rc2, 1.9, 1.9, 1.9.1, 1.9.1, 1.9.2, 1.9.2, 1.9.3, 1.9.3, 1.9.4, 1.9.4, 1.9.5, 1.9.5

[zeebonk]

What do you mean with "Should download all requirements"? You can have only one version of a dependency installed. You have two packages that pin specific different versions, there is no possible way of satisfying this. It is recommended for packages that are used by other packages to use less restrictive versions specifiers. See also: http://python-packaging-user-guide.readthedocs.io/en/latest/distributing/#install-requires

[milin]

I meant should download package A and package B. I was hoping in such a case pip-compile would ask the user which version to chose.

[zeebonk]

If A and B can both work properly with some version of Django, it is clear that the requirements pinned by A and B are too restrictive. But I can imagine that these kind of conflicts aren't that uncommon and sometimes you just don't have the influence to make maintainers of the conflicting packages change the requirements even if you can show that the change in requirements won't break the package. Therefore I think that having pip-compile ask how to resolve this (choose version manually, skip, abort), would be a nice addition.

[nvie]

@zeebonk is correct here. This question has occasionally popped up here, perhaps I should put it in a FAQ of some kind. The purpose of pip-tools is to expose these issues with dependencies. If you don't use pip, you'll get an arbitrary version installed, which leads to undefined behaviour in production if you're unaware of which version you're getting. In this case, package A explicitly declares to be incompatible with any version of Django other than 1.4. Package B ditto for 1.8.7. There is no version of Django that can ever match these version requirements. Picking either version will just lead to trouble with the other package. At the core, this problem needs to be solved by reaching out to the package A and B maintainers and asking them to remove the explicit pinning of dependencies, which is almost always a bad idea. What is typically really meant by ==1.4 is >=1.4 (to express forward-compatibility) or <1.5 (to express backward compatibility.

[milin]

Fair enough. I guess I'd have to contact the the third party owners to update their pinned versions or atleast use >=1.4 in this case.

[milin]

@nvie @zeebonk I am proposing the following solution for this problem. #394. Please take a look and let me know what you think.