Okay, I tried to summarize the discussion and most of my thoughts on that
issue. https://github.com/pypa/pip/issues/988
I'll post anything further I have to say there. I hope to get a student to
measure the extent of the problem...
Thanks,
Justin
On Wed, Apr 15, 2015 at 2:44 PM, Jeremy Stanley
Yes, it's another way to solve the problem. Both backtracking dependency
resolution and ZYpp will always find a solution. The tradeoff is really in
how they function. ZYpp is faster if there are a lot of dependencies that
conflict. The backtracking dependency resolution used in Stork is much
On 4/15/15 9:28 AM, Justin Cappos wrote:
Yes, it's another way to solve the problem. Both backtracking
dependency resolution and ZYpp will always find a solution. The
tradeoff is really in how they function. ZYpp is faster if there are
a lot of dependencies that conflict. The backtracking
See also http://en.wikipedia.org/wiki/ZYpp
On Wed, Apr 15, 2015 at 7:43 AM, Justin Cappos jcap...@nyu.edu wrote:
First of all, I'm surprised that pip doesn't warn or error in this case. I
think this is certainly a bug that should be fixed. The problem can come up
in much more subtle cases
Thanks to Justin Daniel for some insights.
On 15/04/2015 14:28, Justin Cappos wrote:
Yes, it's another way to solve the problem. Both backtracking dependency
resolution and ZYpp will always find a solution. The tradeoff is really in
how they function. ZYpp is faster if there are a lot of
I guess I should provide the code for what I've done in this space also.
Yes, the problem is NP hard, so in both cases, the system may run really
slowly. In practice, you don't tend to have a lot of conflicts you need to
resolve during a package install though. So I'd argue that optimizing for
level 0 A
A level 1 1.4= C
level 0 B
B level 1 1.6= C 1.7
pip manages to download version 1.8 of C(Django) using A's requirement,
but never even warns us that the B requirement of C was violated. Surely
even in the absence of a resolution pip could raise a warning at the end.
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
On 15/04/2015 16:49, Marcus Smith wrote:
..
agreed on the warning, but there is a documented workaround for this, that
is to put the desired constraint for C at level 0 (i.e. in the install args
or in your requirements file)
see case #2 here
On 15 April 2015 at 11:15, David Cournapeau courn...@gmail.com wrote:
This is indeed the case. If you want to solve dependencies in a way that
works well, you want an index that describes all your available package
versions.
While solving dependencies is indeed NP complete, they can be
On Wed, Apr 15, 2015 at 8:56 AM, Robin Becker ro...@reportlab.com wrote:
On 15/04/2015 16:49, Marcus Smith wrote:
..
agreed on the warning, but there is a documented workaround for this, that
is to put the desired constraint for C at level 0 (i.e. in the install
args
or in your
On Wed, Apr 15, 2015 at 11:32 AM, Trishank Karthik Kuppusamy
trish...@nyu.edu wrote:
On 15 April 2015 at 11:15, David Cournapeau courn...@gmail.com wrote:
This is indeed the case. If you want to solve dependencies in a way that
works well, you want an index that describes all your available
On 2015-04-15 12:09:04 +0100 (+0100), Robin Becker wrote:
After again finding that pip doesn't have a correct dependency
resolution solution a colleage and I discussed the nature of the
problem.
[...]
Before the discussion of possible solutions heads too far afield,
it's worth noting that this
On 16 April 2015 at 04:52, David Cournapeau courn...@gmail.com wrote:
On Wed, Apr 15, 2015 at 11:32 AM, Trishank Karthik Kuppusamy
trish...@nyu.edu wrote:
On 15 April 2015 at 11:15, David Cournapeau courn...@gmail.com wrote:
This is indeed the case. If you want to solve dependencies in a
IIRC, Conda (BSD License) takes a SAT solving (e.g. Sudoku) approach:
http://continuum.io/blog/new-advances-in-conda
(such as installing pycosat (MIT License) when I install conda).
Some links to the source:
* https://github.com/conda/conda/blob/master/conda/logic.py
*
After again finding that pip doesn't have a correct dependency resolution
solution a colleage and I discussed the nature of the problem. We examined the
script capture of our install and it seems as though when presented with
level 0 A
A level 1 1.4= C
level 0 B
B level 1 1.6= C 1.7
First of all, I'm surprised that pip doesn't warn or error in this case. I
think this is certainly a bug that should be fixed. The problem can come
up in much more subtle cases too that are very hard for the user to
understand.
The good news is that this is a known problem that happens when
17 matches
Mail list logo
