Backtrack on distributions with invalid metadata #2834
Conversation
| UnavailablePackage::Unparseable => { | ||
| "was found, but the metadata could not be parsed" | ||
| } |
There was a problem hiding this comment.
👍 This is the kind of thing that would be improved by generic metadata in PubGrub... I started work on it but it's a lot.
charliermarsh
force-pushed
the
charlie/filter-metadata
branch
from
997de86
to
4600848
Compare
## Summary Demonstrates some suboptimal behavior in how we handle invalid metadata, which are fixed in #2834. The included wheels were modified by-hand to include invalid structures.
charliermarsh
force-pushed
the
charlie/filter-metadata
branch
2 times, most recently
from
ca77459
to
d3cb9f9
Compare
|
|
||
| × No solution found when resolving dependencies: | ||
| ╰─▶ Because validation==2.0.0 is unusable because its dependencies are | ||
| unusable because the package metadata could not be parsed and you |
There was a problem hiding this comment.
@zanieb - Is there any way for me to improve this (the triple "because") without larger refactors?
There was a problem hiding this comment.
Can I make Dependencies::Unavailable accept an enum or something?
There was a problem hiding this comment.
Maybe you could switch it from a string to an enum but uhh I'm not really sure. This is the idea behind a generic incompatibility metadata type in PubGrub.
There was a problem hiding this comment.
If I can do it, do you mind if I do it?
There was a problem hiding this comment.
No I don't mind it seems like a step in the right direction
There was a problem hiding this comment.
I'll add separately.
charliermarsh
force-pushed
the
charlie/filter-metadata
branch
from
d3cb9f9
to
658bfeb
Compare
| @@ -1100,8 +1100,7 @@ fn mismatched_name() -> Result<()> { | |||
| ----- stdout ----- | |||
|
|
|||
| ----- stderr ----- | |||
| error: Failed to read: foo @ file://[TEMP_DIR]/foo-2.0.1-py3-none-any.whl | |||
| Caused by: The .dist-info directory tomli-2.0.1 does not start with the normalized package name: foo | |||
| error: Because foo was found, but has an invalid format and you require foo, we can conclude that the requirements are unsatisfiable. | |||
There was a problem hiding this comment.
This is slightly worse... I guess I could make the "reasons" more specific?
There was a problem hiding this comment.
Maybe the .dist-info thing is so broken that we shouldn't backtrack. IDK.
There was a problem hiding this comment.
Hm it's a little weird to throw the no solution error this way (i.e. compared to how it's formatted elsewhere)
You could push the detailed reasons into some hints?
There was a problem hiding this comment.
Hm it's a little weird to throw the no solution error this way (i.e. compared to how it's formatted elsewhere)
What do you mean by this?
There was a problem hiding this comment.
error: Because foo was found, ...
vs
× No solution found when resolving dependencies:
╰─▶ Because you require ...
I don't mind the lack of the arrow and such but the "No solution found" part seems relevant.
There was a problem hiding this comment.
Ah yeah. I'll add separately.
charliermarsh
force-pushed
the
charlie/filter-metadata
branch
from
658bfeb
to
f101da3
Compare
|
Filed issues for the follow-ups. |
Summary
Closes #2821.