[Distutils] name of the dependency problem

[Robin Becker]

On 15/04/2015 14:34, Trishank Karthik Kuppusamy wrote:
> On 4/15/15 9:28 AM, Justin Cappos wrote:
.........
>
> ZYpp seems to assume that dependency resolution is an NP-complete problem
> (http://www.watzmann.net/blog/2005/11/package-installation-is-np-complete.html).
>
yes I deduced that this must be some kind of satisfiability problem although 
what the mapping is escapes me right now. Various hints in the stork work seem 
to imply having the version info (and presumably other meta data including 
requirements) stored in fast access some how so that the computations can be 
done fast.

> I agree that we need not solve the problem just yet. It may be worthwhile to
> inspect packages on PyPI to see which package is unsatisfiable, but I am led to
> understand that this is difficult to do because most package metadata is in
> setup.py (runtime information).
>
> Where did you run into this problem, Robin?

this is the reportlab website repository where we have a top level requirements file

for whatever reason that contains a git+https package from github django-mailer 
0.2a1 which has open ended requirement 1.4<=Django, later in the top level 
requirements there's another package that wants 1.6<=Django<1.7, and this 
package coming after never gets a look in so far as Django is concerned.


After looking at the trace and discovering the problem the fix is to move the 
open ended requirement after the closed one. It would have been easier to 
discover the problem if pip had flagged the unsatisfied requirement eg


!!!!!!!!!!!
Django 1.8 loaded because of django-mailer-0.2a1 conflicts with 1.6<=Django<1.7 
required by docengine-0.6.29

but how hard that is I don't know; certainly pip must inspect the requirements 
so it could record the facts and possible spit out the first n conflicts.
-- 
Robin Becker