Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Fix reject of valid state in criteria compatibility check #111
Fix reject of valid state in criteria compatibility check #111
Changes from 15 commits
8931c6d
0d8faa9
568fc6d
525b8c2
47f1e6c
7586575
dabe77d
1809154
8232a17
469e1e5
41ceb33
8e4d2c4
a25f3bc
85c9ce9
65fa410
70c9567
5e85621
7e841f8
cc1c220
ad9eaca
20df2c8
6e9cf49
546a11f
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Empty information is technically allowed but likely unexpected, since it records where a criterion came from, and if a criterion comes from nowhere, should it not be removed?
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.
My reasoning was that we're dropping the constraint provided by a parent because we're dropping the pin on that parent. But if the new pin on the parent happens to have the same constraint (the common case), we might want to keep
incompatibilities
, in order to prevent backtracking over the same thing again.But as I type this I realize that I'm really not yet confident in my understanding of how incompatibilities are gathered. So if you are confident that we can safely drop the criterion when no information remains I'll apply that change. Otherwise I'll have to sink my teeth in the incompatibilities some more.
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 the intent is to keep
incompatibilities
in the graph, I think it’s OK to keep a criterion with empty information (it’s basically an orphan node). We should describe this in the release note (by adding a release note fragment file innews
) so provider/reporter implementers are aware of the possibility thatinformation
could be empty (and what that means), it’s likely no-one would be particular troubled by this since an orphan node can simply be ignored in the final graph anyway.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.
All right, I'll do that. I think
pip
will need a minor change, but there seems to already be a breaking change in master compared to the last release anyway so I guess that is acceptable.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.
I think the orphan nodes will be excluded automatically by
build_result()
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.
Indeed they will for the final result, but not for intermediate calls to the provider, see here: #91 (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.
I've made an attempt at the news fragment but I'm not entirely sure about your change entry conventions.
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.
What errors does this ignore?
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.
Resolution
is not part of the public interface declared insrc/resolvelib/resolvers.pyi
. My reasoning was that for testing that does not matter. I meant to ask about this but I forgot about it. The error is as follows: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.
We can add
Resolution
to the type stubs; I think someone would need it at some point anyway.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.
All right, I'll do that, thanks.
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.
Done. I did have to add another more specific type ignore because the test case monkeypatches a private method. I think that should be acceptable?