Skip to content

Use strict optional checking in legacy resolver #12295

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

Merged
merged 4 commits into from
Apr 23, 2024

Conversation

hauntsaninja
Copy link
Contributor

@hauntsaninja hauntsaninja commented Sep 24, 2023

The assert in _set_req_to_reinstall is definitely correct, the three call sites have guards

The assert in _populate_link is a little trickier. It's not obvious to me how to prove it will never trigger. But do note that if link were ever None, it could potentially cause AttributeError in Cache._get_cache_path_parts and direct_url_from_link

The assert in _resolve_one is safe, if req_to_install.name was None it would raise TypeError in canonicalize_name

I can't prove that req.name is not None in get_installation_order and the code would work fine if that were the case (since it's a defaultdict), so I opted to just ignore

The assert in _set_req_to_reinstall is definitely correct, the three
call sites have guards

The assert in _populate_link is a little trickier. It's not obvious to
me how to prove it will never trigger. Note that if link were ever None,
it could potentially cause AttributeError in Cache._get_cache_path_parts
and direct_url_from_link

The assert in _resolve_one is safe, if req_to_install.name was None it
would raise TypeError in canonicalize_name

I can't prove that req.name is not None in get_installation_order
and the code would work fine if that were the case (since it's a
defaultdict), so I opted to just ignore
@@ -11,7 +11,6 @@
"""

# The following comment should be removed at some point in the future.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
# The following comment should be removed at some point in the future.

@ichard26
Copy link
Member

ichard26 commented Apr 20, 2024

Since the legacy resolver is deprecated and slated for removal (at some point ™️), I don't believe it's worth the effort making it conform to a stricter mypy configuration. Any objections to closing?

@hauntsaninja
Copy link
Contributor Author

The effort has mostly already been spent, the removal date for legacy resolver is unknown, no-strict-optional is totally evil, so if it were me I would just merge. But feel free to close too.

@pfmoore
Copy link
Member

pfmoore commented Apr 20, 2024

I'm OK with progressing this rather than closing it, but the first thing would be to address the review comments.

@hauntsaninja
Copy link
Contributor Author

Oh oops, pushed the change!

Copy link
Member

@pfmoore pfmoore left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have little interest in this change (the legacy resolver is dead, even if we haven't removed it yet) but it looks OK to me.

@ichard26 ichard26 requested a review from uranusjr April 21, 2024 22:53
@uranusjr uranusjr merged commit e812942 into pypa:main Apr 23, 2024
24 checks passed
@hauntsaninja hauntsaninja deleted the legacy-resol branch April 23, 2024 06:54
@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 8, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants