-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simplify graph in get_topological_weights. #10574
Conversation
Fixes #10557 where the resolver spends too much time calculating the weights. Also, do not let `get_installation_order` calculate these weights at all when there is nothing left to install.
Why? This does not touch anything in resolvelib. |
Ah, okay, good. I do see lots of test failures now locally, so it seems I have some more work to do. But the idea can be reviewed. |
Local failures were due to parallel tox runs, I think. |
I am not used to mypy and did not have pre-commit installed yet.
For good measure I tried with slightly older Plone constraints ( Since this is my first PR, two GHA workflows are waiting for approval. I am happy to squash the commits if that is preferred. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If tests pass (I think they will)
After minor refactoring, the condition was the wrong way around.
'next' gives mypy errors.
The
Any idea how to solve that? I have not worked with I tried adding a method to
and then calling
Okay, I went with the slightly more verbose code that @jbylund suggested, and now mypy is happy. Can you restart the workflow please? |
FWIW, |
I could see a future reader being confused about if there's somehow a copy of the graph due to the comments. My inclination would be to phrase this as an iterative (while can simplify graph) rather than the recursive, but that's just because of my perception that people find that a little easier to reason about. Curious to hear other takes on recursive v iterative here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The general idea looks excellent for me!
There seems agreement that my PR is fine. There is only the comment from @jbylund who wonders if it would be better to do
If I do this, would it help this PR along towards merging? Anything else I can do? Should I squash to one commit? Should I rebase on the main branch? |
Converting traversal to a loop is likely a good idea; it’s not terribly likely we’d go over Python’s recursing limit (Python dependencies are generally not that deep; we’re not JavaScript), but you never know. I can’t really speak to whether that’d help get this merged though. I want more people to take a look at the logic if possible, but if no-one raises any issues this will go in the next release. Note that we don’t expect to release anything until January 2022 anyway so it doesn’t really matter that much if this is merged very soon. |
This is easier to wrap your head around.
Thanks for the info. Okay, I have turned the recursive function into a loop. |
Co-authored-by: Tzu-ping Chung <uranusjr@gmail.com>
weight = len(graph) - 1 | ||
for leaf in leaves: | ||
weights[leaf] = weight | ||
# Remove the leaves from the copy of the graph, making the copy simpler. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Possibly misleading comment, as there is no longer a copy of the graph.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, you are right. You mentioned this earlier, but I misunderstood, thinking your comment was outdated, referring to an older version of my PR.
I have fixed the comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Up to you if you feel like the docstring of get_installation_order
could be updated, since I don't think it's a great explanation of what's going on in the method. But looks good, thanks for the contribution.
I have updated the docstring of
Thank you, and thanks for the review! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great and is super smart!
Thanks @mauritsvanrees! ^.^ |
Fixes #10557 where the resolver spends too much time calculating the weights.
Also, do not let
get_installation_order
calculate these weights at all when there is nothing left to install.I had to change one test in
test_resolver.py
because some weights have changed. The test was meant to address this comment and I think the new weights with new order are okay. Translated to that comment, the new order is that B is installed before D, but that should not matter, because A is still installed first, before C, which is the point of the comment.This is my first PR for
pip
.I wonder: should this PR be done in https://github.com/sarugaku/resolvelib first?
Meanwhile, let me share the output of a few runs with extra print statements.
Installing
Zope
:Same with
Products.CMFPlone
(a much larger superset of Zope):So 35 packages in the graph is the maximum simplification. The original
visit
function is called on the remaining graph.Same with
Plone
(a slightly larger superset ofProducts.CMFPlone
):In the last case, extra packages needed to be installed, and this order was calculated:
That seems right. For example
certify
is installed beforerequests
, andPlone
is installed last.