
Seeking Developers for Paid Contract Improving Pip - Liriel
https://pyfound.blogspot.com/2019/11/seeking-developers-for-paid-contract.html
======
dimino
This is great news, very excited to see the fruits of this labor.

Skip to here for a bit more info:
[https://github.com/pypa/pip/issues/988#issuecomment-55267449...](https://github.com/pypa/pip/issues/988#issuecomment-552674491)

An explanation of the problem and the solution's approach:
[https://docs.google.com/document/d/1x_VrNtXCup75qA3glDd2fQOB...](https://docs.google.com/document/d/1x_VrNtXCup75qA3glDd2fQOB2TakldwjKZ6pXaAjAfg/edit)

------
jgresty
I would have thought dependency resolution would be a solved problem by now,
given how many different projects all need to do it well.

Can anyone explain why there needs to be a new solver just for pip instead of
adding support for python packages to something like libsolv[0].

[0] [https://github.com/openSUSE/libsolv](https://github.com/openSUSE/libsolv)

~~~
crgwbr
I would imagine that evaluating solutions like that would be part of this
contract.

~~~
uranusjr
SAT solutions, including libsolv, is (somewhat surprisingly) not a suitable
solution for pip, and Python packages in general, at least at the present
time. The Google Doc link in dimino’s comment[1] covers the issues quite
thoroughly (at around page 10–12).

What I understand from the RfP is that evaluating work is basically done, and
the main work is to integrate the backtracking implementation into pip. But
one of the more important task listed IMO is to untangle the current resolver
implementation from other pip components. This implies that 1) the new
resolver will be a relatively isolated component, allowing code reuse for
alternative package managers, and 2) the resolver can more easily switch to a
SAT solution when it becomes viable to do so.

[1]:
[https://news.ycombinator.com/item?id=21512322](https://news.ycombinator.com/item?id=21512322)

