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.htm...).
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