Skip to content
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

Merged

Conversation

konstin
Copy link
Member

@konstin konstin commented Apr 15, 2024

Restructure the incompatibility into pubgrub internal metadata and a custom external type.

The internal types are:

  • not root: The root incompatibility that drives resolution
  • no versions: We tried all versions and there is none remaining
  • from dependency of: {A, not B} from A -> B
  • derived from: {A, not C} from {A, not B} and {B, not C}
  • custom: Any incompatibility that originates outside pubgrub. The idea is that users can set M to a custom enum of theirs. 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.
    • The package has invalid metadata

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.

@konstin konstin force-pushed the konsti/dev/custom-incompatibility-metadata branch from fe96e23 to 8838dca Compare April 15, 2024 13:16
Comment on lines +67 to +72
/// 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),
Copy link
Member

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

Copy link
Member Author

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

Copy link
Member

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.

Copy link
Member Author

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

Copy link
Member

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.

Copy link
Member

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.

Copy link
Member

@mpizenberg mpizenberg Apr 17, 2024

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.

Copy link
Member Author

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

@Eh2406
Copy link
Member

Eh2406 commented Apr 16, 2024

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.

let self_metadata = self.metadata();
if self_metadata != other.metadata() {
return None;
}
Copy link
Member

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?

Copy link
Member Author

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

Copy link
Member

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
Copy link
Member Author

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

@konstin
Copy link
Member Author

konstin commented Apr 17, 2024

Should we create a trait for M: Eq + Clone + Debug + Display?

@konstin konstin marked this pull request as ready for review April 17, 2024 08:33
@Eh2406
Copy link
Member

Eh2406 commented Apr 27, 2024

Yes. I think we should have a trait. Although it could be in a follow-up PR. It should, one day, have a method can_merge(&Self, &Self) -> Option<Self> instead of the Eq bound. None would mark that the two incompatibilities should not be merged. And Some(M) would provide the new metadata for the merged incompatibility. That would allow a error like "unavailable because of HTTP 404, with request ID 123456789" to be merged with "unavailable because of HTTP 404, with request ID 987654321" even though they are not structurally equal.

Copy link
Member

@Eh2406 Eh2406 left a 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.

@Eh2406 Eh2406 added this pull request to the merge queue May 1, 2024
Merged via the queue into pubgrub-rs:dev with commit d5ed801 May 1, 2024
5 checks passed
@konstin konstin deleted the konsti/dev/custom-incompatibility-metadata branch May 1, 2024 21:23
konstin added a commit to astral-sh/uv that referenced this pull request May 8, 2024
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants