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

Simplify pep440 -> version ranges conversion #8683

Merged
merged 1 commit into from
Oct 30, 2024
Merged

Conversation

konstin
Copy link
Member

@konstin konstin commented Oct 29, 2024

With #8669 as preparation, we can remove what used to be the PubGrubSpecifier and instead implement a direct conversion from VersionSpecifiers to Range<Version>. Thanks to #8669 (comment), this conversion is infallible, removing a lot of fallibility downstream.

The conversion takes an owned value, to signal that we consume the value. Previously, the function had cloned the version internally.

@konstin konstin added the internal A refactor or improvement that is not user-facing label Oct 29, 2024
@konstin konstin requested a review from BurntSushi October 29, 2024 20:26
With #8669 as preparation, we can remove what used to be the `PubGrubSpecifier` and instead implement a direct conversion from `VersionSpecifiers` to `Range<Version>`. Thanks to #8669 (comment), this conversion is infallible, removing a lot of fallibility downstream.

The conversion takes an owned value, to signal that we consume the value. Previously, the function had cloned the version internally.
Copy link
Member

@BurntSushi BurntSushi left a comment

Choose a reason for hiding this comment

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

I like it!

fn from(specifiers: VersionSpecifiers) -> Self {
let mut range = Ranges::full();
for specifier in specifiers {
range = range.intersection(&Self::from(specifier));
Copy link
Member

Choose a reason for hiding this comment

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

At first, I thought this might have been allocating a new Ranges<Version> only to throw it away, but I think Ranges::from(specifier) in this case always creates a Ranges<Version> with one range? (Possibly two?) If so, and I believe since it uses smallvec internally, there's no alloc happening.

I don't have any suggestions for the immediate term, but if this ever showed up on a profile, there might be some room for micro-optimization here. (Perhaps requiring API changes to version-ranges. Not sure.)

Copy link
Member

Choose a reason for hiding this comment

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

Also guessing that this is mostly moved code and not newly written.

Copy link
Member Author

Choose a reason for hiding this comment

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

Agreed, keeping it since it's the same overhead as it was before the refactoring.

@@ -11,7 +11,7 @@ use crate::RequiresPython;
#[test]
fn requires_python_included() {
let version_specifiers = VersionSpecifiers::from_str("==3.10.*").unwrap();
let requires_python = RequiresPython::from_specifiers(&version_specifiers).unwrap();
Copy link
Member

Choose a reason for hiding this comment

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

Nice!

@@ -362,7 +362,7 @@ async fn init_project(
}
ref
python_request @ PythonRequest::Version(VersionRequest::Range(ref specifiers, _)) => {
let requires_python = RequiresPython::from_specifiers(specifiers)?;
Copy link
Member

Choose a reason for hiding this comment

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

Nice!

@konstin konstin merged commit c1a0fb3 into main Oct 30, 2024
63 checks passed
@konstin konstin deleted the konsti/version-ranges-3 branch October 30, 2024 12:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
internal A refactor or improvement that is not user-facing
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants