-
-
Notifications
You must be signed in to change notification settings - Fork 637
Make BacktrackingResolver ignore extras when dropping existing constraints #1984
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
Make BacktrackingResolver ignore extras when dropping existing constraints #1984
Conversation
Co-authored-by: chrysle <[email protected]>
|
I found that |
|
I wasn't aware of that function. Say, also since it's already used in resolver.py, wouldn't it be easier to just use it on the output of Sorry for pushing you around. |
|
No problem, sometimes implementations need multiple iterations before the best approach becomes apparent. I will take a look in the evening how to simplify the PR this way. |
atugushev
left a 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.
Thanks for the fix! While I don't mind unit tests, I'd prefer having an integration test instead. Mocking around with private methods like Resolver._do_resolve() could lead to extra work during future internal refactoring.
Could you please add at least one "success" integration test in test_cli_compile.py to confirm that the issue is resolved? Use test_cli_compile_strip_extras as a reference.
|
@atugushev: I replaced the unit test with an integration test as you proposed. I gather from These functions have "complex" signatures (too complex for |
This however sounds like an issue that should be investigated. Haven't found something loadable yet, though. |
|
@chrysle: For demonstration's sake, I added pre-commit rejected this commit, here's the relevant output: |
I guess that's unrelated; it's just rebuilding its cache. |
Right, with What do you want me to do about the annotations (and, in particular, the protocol classes) I added to the tests? Should I take them out again (or, maybe, move the protocol classes into a dedicated module, because they don't really fit into |
I think that would be the better solution, since it's otherwise unnecessary complex. |
Done. |
As discussed with chrysle, pinning of the dependencies in pyproject.toml will be addressed in the context of #1927. Co-authored-by: chrysle <[email protected]>
|
Thank you! |
This PR resolves #1977.
When the backtracking resolver collected the names of incompatible install requirements, it used to apply
utils.key_from_reqto the requirements listed in the exception causes. According to the type hints,utils.key_from_reqexpects either apip._internal.req.req_install.InstallRequirementor apip._vendor.packaging.requirements.Requirement. In some cases, though, the object passed is apip._internal.resolution.resolvelib.requirements.SpecifierRequirement(i.e., a specialization ofpip._internal.resolution.resolvelib.base.Requirement).All mentioned classes define an attribute
name. In case ofInstallRequirementand theRequirementfrom the vendor package, the name holds the bare package name. In case of theRequirementfrom the resolvelib package, the name includes the extras (if any).key_from_reqis used in other places as well, I don't know whether they rely on the existing behavior. Therefore, I added a new functionutils.key_no_extra_from_reqthat also accepts instances ofpip._internal.resolution.resolvelib.base.Requirementand keeps only the part of the name up to the first opening square bracket (if any).I was surprised I did not find more tests of the backtracking resolver. In the end, I followed the example of
test_catch_distribution_not_found_errorand directly called the backtracking resolver's method_do_resolvewith a mocked pip resolver object.Furthermore, I had to add pytest to the config of the mypy-mirror pre-commit hook.
I still got "untyped def" errors from
test_resolver.py, even though there's an override for test modules in pyproject.toml that is supposed to disable this check. I therefore had the impression that mypy-mirror ignores the mypy config in pyproject.toml. I didn't investigate this any further, though, and simply annotated the all parameters of my test.Contributor checklist
Maintainer checklist
backwards incompatible,feature,enhancement,deprecation,bug,dependency,docsorskip-changelogas they determine changelog listing.