On 10 Feb 2017 23:05, "Justin Cappos" wrote:
I think the difference Sebastien is trying to say is that you need info
from *all* pieces of static metadata. Not just that from the packages you
will end up installing.
Backtracking dependency resolution will be much more like the
Hi all,
Assuming that all the requirements are wheels and coming from PyPI.
Installed using a recent pip.
How often do you think the resolution will be the same for all
clients, and mostly be "pull everything from latest" ?
If so, would it make sense to pre-compute thing on PyPI/warehouse at
I think the difference Sebastien is trying to say is that you need info
from *all* pieces of static metadata. Not just that from the packages you
will end up installing.
Backtracking dependency resolution will be much more like the wheel model.
If one does not backtrack (which is true most of
On Fri, Feb 10, 2017 at 4:28 PM, Justin Cappos wrote:
> So, there aren't "heuristics" to tweak here. The algorithm just encodes
> the rules for trying package combinations (usually, latest version first)
> and then backtracks to a previous point when an unresolvable conflict is
> On Feb 10, 2017, at 2:53 PM, Sebastien Awwad wrote:
>
> If dependencies were knowable in static metadata, there would be a decent
> case for SAT solving. I'll try to get back to a write-up after the current
> rush on my main project subsides.
The differences
So, there aren't "heuristics" to tweak here. The algorithm just encodes
the rules for trying package combinations (usually, latest version first)
and then backtracks to a previous point when an unresolvable conflict is
found. This is quite different from something like a SAT solver where it
does
On Fri, Feb 10, 2017 at 3:52 PM, David Cournapeau
wrote:
>
>
> On Fri, Feb 10, 2017 at 2:33 PM, Justin Cappos wrote:
>
>> Yes, don't use a SAT solver. It requires all metadata from all packages
>> (~30MB uncompressed) and gives hard to predict results in
On Fri, Feb 10, 2017 at 3:52 PM, David Cournapeau
wrote:
>
>
> On Fri, Feb 10, 2017 at 2:33 PM, Justin Cappos wrote:
>
>> Yes, don't use a SAT solver. It requires all metadata from all packages
>> (~30MB uncompressed) and gives hard to predict results in
On Fri, Feb 10, 2017 at 2:33 PM, Justin Cappos 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.
Also the
While there may be some clever way of delivering changes to dependency
metadata that consumes less bandwidth (The first delivery for a client will
be somewhat large, but versioned metadata information plus compressed
deltas could move clients from one version of the full metadata set to
another,
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.
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
>From the discussion on
https://github.com/pypa/pip/issues/988#issuecomment-279033079:
- https://github.com/ContinuumIO/pycosat (picosat)
- https://github.com/ContinuumIO/pycosat/blob/master/pycosat.c (C)
- https://github.com/ContinuumIO/pycosat/blob/master/picosat.c
-
Yay! Thank you so much for a prompt and positive response! I'm pretty
excited and looking forward to this.
On Thu, Feb 9, 2017, 20:23 Donald Stufft wrote:
I’ve never done it before, but I’m happy to provide mentoring on this.
On Feb 8, 2017, at 9:15 PM, Pradyun Gedam
13 matches
Mail list logo