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

Apply extra to overrides and constraints #4829

Merged
merged 1 commit into from
Jul 9, 2024

Conversation

konstin
Copy link
Member

@konstin konstin commented Jul 5, 2024

This is an attempt to solve https://github.com/astral-sh/uv/issues/ by applying the extra marker of the requirement to overrides and constraints.

Say in a we have a requirements

b==1; python_version < "3.10"
c==1; extra == "feature"

and overrides

b==2; python_version < "3.10"
b==3; python_version >= "3.10"
c==2; python_version < "3.10"
c==3; python_version >= "3.10"

Our current strategy is to discard the markers in the original requirements. This means that on 3.12 for a we install b==3, but it also means that we add c to a without a[feature], causing #4826. With this PR, the new requirement become,

b==2; python_version < "3.10"
b==3; python_version >= "3.10"
c==2; python_version < "3.10" and extra == "feature"
c==3; python_version >= "3.10" and extra == "feature"

allowing to override markers while preserving optional dependencies as such.

Fixes #4826

@charliermarsh
Copy link
Member

I think we do need to join extra markers specifically here...

@charliermarsh
Copy link
Member

Another reasonable option would be to ignore markers in the overrides file and just respect the original markers, but that means you can't replace dependencies on a per-platform basis.

@konstin konstin force-pushed the konsti/join-markers-for-requirements branch from 388cdda to 43762b2 Compare July 8, 2024 10:59
@konstin konstin changed the title Join requirement and override markers Apply extra to overrides and Jul 8, 2024
@konstin konstin changed the title Apply extra to overrides and Apply extra to overrides and constraints Jul 8, 2024
@konstin konstin force-pushed the konsti/join-markers-for-requirements branch from 43762b2 to 16a0a7c Compare July 8, 2024 11:02
@konstin konstin marked this pull request as ready for review July 8, 2024 11:11
@konstin
Copy link
Member Author

konstin commented Jul 8, 2024

Changed this to only apply extras, properly ready now.

@@ -1466,7 +1466,7 @@ impl<InstalledPackages: InstalledPackagesProvider> ResolverState<InstalledPackag
true
})
.flat_map(move |requirement| {
iter::once(Cow::Borrowed(requirement)).chain(
iter::once(requirement.clone()).chain(
Copy link
Member

Choose a reason for hiding this comment

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

Why clone here?

Copy link
Member Author

Choose a reason for hiding this comment

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

This is now a Cow, so we're generally cloning a ref still. Trying to avoid this clone cause the borrow checker to yell a lot because we're using a reference to the requirement for the chained iterator and it doesn't like the closures with a reference to a value we're also moving.

@konstin konstin merged commit 53db63f into main Jul 9, 2024
49 checks passed
@konstin konstin deleted the konsti/join-markers-for-requirements branch July 9, 2024 18:37
// Case 3: An optional dependency with constraint(s).
//
// When the original requirement is an optional dependency, the constraint(s) need to
// be optional for the same extra, otherwise we activate extras that should be inactive.
Copy link
Member

Choose a reason for hiding this comment

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

@konstin -- This is really random, but is this necessary for constraints? By adding a constraint, we know that the base package was added as a dependency, right?

Copy link
Member

Choose a reason for hiding this comment

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

Also, we already merge markers for constraints.

Copy link
Member Author

Choose a reason for hiding this comment

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

Hmm not sure, i imagine something like:

constraint: bar <2

requirement: root[foo] -> bar

In that case, we should only add bar<2 for root[foo], not for root.

But it could also be we only need this for overrides.

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.

uv pip installs all requirements in --override even though nothing depends on them
2 participants