-
Notifications
You must be signed in to change notification settings - Fork 3k
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 parsing of JSON index dist-info-metadata values #12078
Conversation
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 assume this is just fixing the pip bug, and not a draft of PEP 714, so with that assumption this looks fine to me.
src/pip/_internal/models/link.py
Outdated
|
||
hashes: Optional[dict[str, str]] | ||
|
||
# TODO: Do we care about stripping out unsupported hash methods? |
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 don't have a strong preference since the values in _SUPPORTED_HASHES
look fine to me (though it might be time to retire md5
from that list). In theory people can use a number of other hashes that this method may not pick up, but I think that can/should be handled as a separate task of maintaining the list of supported hashes.
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.
Seems reasonable. This is mostly about handling garbage produced by incorrect servers (stuff like "sah256=abcbcba") than about limiting what hashes we use.
The attribute is already a weird tri-state thing (None
= no data supplied, MetadataFile(None)
= supplied with no hashes, and the full thing with hashes. There's also a dodgy MetadataFile({})
which we get if we end up stripping everything, which is probably like `MetadataFile(None), but consumers might not like an empty dict of hashes.
I think what I should probably do is validate the input up front, rather than in this class. Then we just assert here that hashes must be None
or a dictionary containing only one or more supported hash types.
At the moment, yes. Once I have the bug fixed, it will be easy to rename the attribute1. I will do this in the same PR, as the bug fix is of little value without the renaming. Footnotes
|
OK, PEP 714 has now been included in this. Once CI has passed, it's ready for any final review. It shouldn't be merged until PEP 714 has been accepted, so I'll leave it as draft until then. |
I'm confused. Lint works fine locally for me, even though pre-commit.ci fails in CI. (And if I make the fixes CI wants, local lint fails 🙁) What should I do? Is Ping @pradyunsg as I think the pre-commit.ci stuff was added by you? |
It looks like pre-commit.ci has been failing for some time, including on main: https://results.pre-commit.ci/repo/github/1446467 I'm a little annoyed with pre-commit.ci if they don't produce the same results as a local run of pre-commit 🙁 |
It should behave the same as running it locally. |
Yea, it does. I wonder if there's some sort of state on your end -- does running (if you don't have pre-commit already installed, you can run the lint job and then use the CLI from |
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.
LGTM, with a nit-pick.
src/pip/_internal/models/link.py
Outdated
if len(hashes) > 0: | ||
return hashes | ||
return None |
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.
nit:
if len(hashes) > 0: | |
return hashes | |
return None | |
if not hashes: | |
return None | |
return hashes |
Sightly less C-like, and easier to read. :)
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.
Fixed, thanks (commit incoming once I get pre-commit to behave).
Yes, it does. All sorted now. It's frustrating I can't immediately see where pre-commit is holding that state. I looked, in the project directory and in my home directory, but there wasn't anything obvious. I must admit I didn't look for a subcommand to do it. Also, how have we had main failing with lint checks and not noticed? It looks like we don't have any particularly visible indicator that main is passing CI (I assume we do run CI against main...) Is that all it is, we don't make the results of CI against main visible so no-one noticed? |
I'm getting really annoyed with that RAM disk failure... |
Phew! Randomly re-running the tests FTW... |
Fixes #12042