[Distutils] GSoC 2017 - Working on pip
jcappos at nyu.edu
Fri Feb 10 16:22:56 EST 2017
On Fri, Feb 10, 2017 at 3:52 PM, David Cournapeau <cournape at gmail.com>
> On Fri, Feb 10, 2017 at 2:33 PM, Justin Cappos <jcappos at nyu.edu> wrote:
>> Yes, don't use a SAT solver. It requires all metadata from all packages
>> (~30MB uncompressed) and gives hard to predict results in some cases.
> I doubt there exists an algorithm where this is not the case.
Okay, so there was a discussion about the pros and cons (including
algorithms like backtracking dependency resolution which do not require all
metadata) a while back on the mailing list:
(I believe you may have seen this before because you replied to a message
further down in the thread.)
> Also the lack of fixed dependencies is a substantial problem for a SAT
>> solver. Overall, we think it makes more sense to use a simple backtracking
>> dependency resolution algorithm.
> As soon as you want to deal with version ranges and ensure consistency of
> the installed packages, backtracking stops being simple rather quickly.
Can you explain why you think this is true?
I agree lack of fixed dependencies is an issue, but I doubt it is specific
> to a SAT solver. SAT solvers have been used successfully in many cases now:
> composer (php), dnf (Red Hat/Fedora), conda or our own packages manager at
> Enthought in python, 0install.
> I would certainly be interested in seeing a proper comparison with other
Sure, there are different tradeoffs which make sense in different domains.
Certainly, if you have a relatively small set of packages with statically
defined dependencies and already are distributing all package metadata to
clients, a SAT solver will be faster at resolving complex dependency
We can provide the data we gathered (maybe others provide get some data
too?) and then the discussion will be more grounded with numbers.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Distutils-SIG