-
Notifications
You must be signed in to change notification settings - Fork 37
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
Generic reason for custom incompatibility #208
Generic reason for custom incompatibility #208
Conversation
Co-authored-by: Zanie Blue <[email protected]>
fe96e23
to
8838dca
Compare
/// The package is unavailable for reasons outside pubgrub. | ||
/// | ||
/// Examples: | ||
/// * The version would require building the package, but builds are disabled. | ||
/// * The package is not available in the cache, but internet access has been disabled. | ||
Custom(P, VS, M), |
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.
Should we just call this Unavailable
or Unusable
? We talked about this a little back in #153
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'm trying to name this something that says it's outside pubgrub, unavailable/unusable sounds too much like it could come from the resolution itself
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 wonder if External
is overloaded.
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.
There's the External
type in derivation tree. It's more non-derived than external, but it would be an invasive change
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.
Yeah I agree that's my concern about it being overloaded 🤷♀️ I find it confusing there honestly but curious to see what Jacob thinks of all this.
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 came in expecting to want Unusable
, but the discussion has made me less certain. @mpizenberg is the one with a knack for naming things.
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 generally like this change. I will have a bit of time to review code/naming after May (I have a conf talk next week and changing job end of this month). Otherwise consider I'm ok with it and might (or not) suggest a renaming PR later.
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 could merge away external and use that name here instead: dev...astral-sh:pubgrub:konsti/dev/merge-external
Sorry for the delay. I just had a chance to look at the diff, and I absolutely love it. Thank you so much! I need to poke at this in an editor before I write up the few nits I have. |
src/internal/incompatibility.rs
Outdated
let self_metadata = self.metadata(); | ||
if self_metadata != other.metadata() { | ||
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.
I don't think this code path is needed at the moment, because we can only get here if as_dependency
is Some
and dependencies can't hold metadata. But perhaps they should be able to hold metadata, like what file and line number this dependency edge came from.
Thoughts?
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.
Removed it unless @zanieb wants to keep this
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 actually were just talking about needing that... but it can wait :D
/// because its list of dependencies is unavailable. | ||
pub fn unavailable_dependencies(package: P, version: VS::V) -> Self { | ||
/// Create an incompatibility for a reason outside pubgrub. | ||
#[allow(dead_code)] // Used by uv |
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 also drop this here and only use it in our fork
Should we create a trait for |
Yes. I think we should have a trait. Although it could be in a follow-up PR. It should, one day, have a method |
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 poked at this in an editor, and rustc
told me why everything was there.
Adding a trait and renaming the type can be done in follow-up PR's.
Pubgrub got a new feature where all unavailability is a custom, instead of the reasonless `UnavailableDependencies` and our custom `String` type previously (pubgrub-rs/pubgrub#208). This PR introduces a `UnavailableReason` that tracks either an entire version being unusable, or a specific version. The error messages now also track this difference properly. The pubgrub commit is our main rebased onto the merged pubgrub-rs/pubgrub#208, i'll push `konsti/main-rebase-generic-reason` to `main` after checking for rebase problems.
Restructure the incompatibility into pubgrub internal metadata and a custom external type.
The internal types are:
M
to a custom enum of theirs. Examples:I'm currently working on adapting the formatting to adapt to the uv of this. This should reduce our diff significantly.
This refactoring is relevant to collapsing custom incompatibilities, but i haven't looked into this properly yet.