Add support for `package`-level conflicts in workspaces by zanieb · Pull Request #14906 · astral-sh/uv

zanieb · 2025-07-25T20:03:10Z

Revives #9130

Previously, we allowed scoping conflicting extras or groups to specific packages, e.g. ,{ package = "foo", extra = "bar" } for a conflict in foo[bar]. Now, we allow dropping the extra or group bit and using { package = "foo" } directly which declares a conflict with foo's production dependencies.

This means you can declare conflicts between workspace members, e.g.:

[tool.uv]
conflicts = [[{ package = "foo" }, { package = "bar" }]]

would not allow foo and bar to be installed at the same time.

Similarly, a conflict can be declared between a package and a group:

[tool.uv]
conflicts = [[{ package = "foo" }, { group = "lint" }]]

which would mean, e.g., that --only-group lint would be required for the invocation.

As with our existing support for conflicting extras, there are edge-cases here where the resolver will not fail even if there are conflicts that render a particular install target unusable. There's test coverage for some of these. We'll still error at install-time when the conflicting groups are selected. Due to the likelihood of bugs in this feature, I've marked it as a preview feature.

I would not recommend reading the commits as there's some slop from not wanting to rebase Andrew's branch.

This makes a lot more sense as a name IMO. And I think also works better for the immediate future, where I plan to add a `Project` kind.

Basically, this new conflict kind means that the entire project conflicts with a dependency group or an extra. This just adds the variant. In the next commit, we'll actually make it work.

Supporting project level conflicts ends up being pretty tricky, mostly because depenedency groups are represented as dependencies of the project you're trying to declare a conflict for. So by filtering out the project in the fork for the conflicting group, you end up filtering out the group itself too. To work-around this, we add a `parent` field to `PubGrubDependency`, and use this to filter based on project conflicts. This lets us do "delayed" filtering by one level. The rest of the changes in this commit are for reporting errors when you try to activate the group without disabling the project.

There was a fair bit of support for project level conflicts missing from `UniversalMarker`. I think that's because my initial PR pre-dated the beefing up of `UniversalMarker`.

This reverts commit 3c1057d.

BurntSushi

Nice, I think this LGTM. I think it would still be good to get @charliermarsh's review on the parent package stuff I added (I left a comment noting where).

I was curious what else you did here to make the remaining cases work?

BurntSushi · 2025-07-29T18:10:54Z

crates/uv-resolver/src/pubgrub/dependencies.rs

+    /// group as a dependency of that package. So if you filter out the package
+    /// in a fork due to a conflict, you also filter out the group. Therefore,
+    /// we introduce this parent field to enable "delayed" filtering.
+    pub(crate) parent: Option<PackageName>,


IIRC, this is the thing I was most uncertain about @charliermarsh

I'm also not 100% sure on the implications here...

BurntSushi · 2025-07-29T18:15:41Z

crates/uv/tests/it/lock.rs

+    ");
+
+    Ok(())
+}


@zanieb These locks LGTM I think. What did you do to make this case work?

To get detect_conflicts to pass, I needed to add

uv/crates/uv/src/commands/project/mod.rs

Lines 2513 to 2516 in 1dc7840

if !packages.contains(item.package()) {

// Ignore items that are not in the install targets

continue;

}

which required, more broadly, understanding the subset of package we were reasoning about during conflict detection.

Then there were some minor problems in the forking logic. The main thing was

uv/crates/uv-resolver/src/resolver/mod.rs

Lines 3792 to 3798 in 1dc7840

// We should not filter entire projects unless they're a top-level dependency

// Otherwise, we'll fail to solve for children of the project, like extras

ConflictKindRef::Project => {

if dep.parent.is_some() {

return true;

}

}

BurntSushi · 2025-07-29T18:17:19Z

crates/uv/tests/it/lock.rs

+                { package = "example" },
+                # TODO(zanieb): Technically, we shouldn't need to include the extra in the list of
+                # conflicts however, the resolver forking algorithm is not currently sophisticated
+                # enough to pick this up by itself


Oh interesting. Could this be added outside of the resolver automatically? Hmm, no, I don't think so. It could only be done in the "direct" case I think? Is there a test for the indirect/transitive case? I looked below but I don't think I see this work-around used anywhere else.

I looked into that a bit but decided to cut scope. It seems quite plausible to update the resolver to handle this case when forking.

There is lock_conflicting_workspace_members_depends_transitive_extra but in that case there's a conflict that should not be resolved. I didn't add a transitive case like this one — I felt like I was going to end up playing whackamole with a bunch of complicated test cases. I think if it wasn't in preview, I wouldn't be comfortable without doing a lot more testing.

charliermarsh · 2025-08-01T02:02:12Z

crates/uv-configuration/src/preview.rs

        const JSON_OUTPUT = 1 << 2;
        const PYLOCK = 1 << 3;
        const ADD_BOUNDS = 1 << 4;
+        const PACKAGE_CONFLICTS = 1 << 5;


What's the thinking behind releasing this under a flag?

It's in the summary

As with our existing support for conflicting extras, there are edge-cases here where the resolver will not fail even if there are conflicts that render a particular install target unusable. There's test coverage for some of these. We'll still error at install-time when the conflicting groups are selected. Due to the likelihood of bugs in this feature, I've marked it as a preview feature.

I'm just not sure we'll be able to meet our bar for correctness here in the first iteration.

crates/uv-resolver/src/pubgrub/dependencies.rs

charliermarsh · 2025-08-01T02:05:34Z

crates/uv-resolver/src/resolver/mod.rs

+            match conflicting_item.kind() {
+                // We should not filter entire projects unless they're a top-level dependency
+                // Otherwise, we'll fail to solve for children of the project, like extras
+                ConflictKindRef::Project => {


Nit: use a matches! since there's only one active branch here?

I wanted it to be exhaustive so it needs to be revisited if we add another kind, but I don't feel strongly.

crates/uv/src/commands/project/install_target.rs

charliermarsh · 2025-08-01T02:15:55Z

crates/uv-resolver/src/pubgrub/dependencies.rs

+    /// group as a dependency of that package. So if you filter out the package
+    /// in a fork due to a conflict, you also filter out the group. Therefore,
+    /// we introduce this parent field to enable "delayed" filtering.
+    pub(crate) parent: Option<PackageName>,


I'm also not 100% sure on the implications here...

crates/uv-resolver/src/pubgrub/dependencies.rs

BurntSushi and others added 22 commits November 15, 2024 07:30

uv-pypi-types: rename ConflictPackage to ConflictKind

10d5ac1

This makes a lot more sense as a name IMO. And I think also works better for the immediate future, where I plan to add a `Project` kind.

uv-pypi-types: add ConflictKind::Project

9026ff2

Basically, this new conflict kind means that the entire project conflicts with a dependency group or an extra. This just adds the variant. In the next commit, we'll actually make it work.

Merge branch 'main' into ag/package-level-conflict

1370e51

Merge branch 'main' into ag/package-level-conflict

dd410d0

Fully support project level conflicts

6ca33c7

There was a fair bit of support for project level conflicts missing from `UniversalMarker`. I think that's because my initial PR pre-dated the beefing up of `UniversalMarker`.

Update detect_conflicts to take a InstallTarget

c379db0

Add packages utility to InstallTarget

d54792b

Do not include conflicts for packages that will not be installed

95b6b20

Add test cases, improve packages(), fix errors

827708e

Improve handling of package conflicts

88eb0e9

Log resolver environments

3c1057d

Remove unused dependency

d46a0f2

Cleanup test

9105464

Add more test cases

41b576b

CLippy

a4eff02

Add another extra test case

3fea806

Remove test cases moved to #14879

8e41471

Revert "Log resolver environments"

05ce345

This reverts commit 3c1057d.

Update comments

a5ce1df

Expand comment

fb0ca39

Add preview warning

49a75fa

zanieb mentioned this pull request Jul 25, 2025

How to build dependencies with path as a source #14526

Open

zanieb added 3 commits July 25, 2025 15:11

Merge branch 'main' into zb/package-conflicts

22cce9d

Merge with preview flag work

55360d3

Merge branch 'main' into zb/package-conflicts

64a24f8

zanieb temporarily deployed to uv-test-registries July 25, 2025 20:31 — with GitHub Actions Inactive

Add preview feature list

7927fb3

zanieb force-pushed the zb/package-conflicts branch from 62a084f to 7927fb3 Compare July 25, 2025 20:36

zanieb temporarily deployed to uv-test-registries July 25, 2025 20:38 — with GitHub Actions Inactive

zanieb mentioned this pull request Jul 25, 2025

add support for package level conflicts with groups #9130

Closed

zanieb force-pushed the zb/package-conflicts branch from 0691c7a to 84fdb18 Compare July 25, 2025 20:53

zanieb temporarily deployed to uv-test-registries July 25, 2025 20:56 — with GitHub Actions Inactive

Fixup check

1dc7840

zanieb force-pushed the zb/package-conflicts branch from 84fdb18 to 1dc7840 Compare July 25, 2025 21:14

zanieb temporarily deployed to uv-test-registries July 25, 2025 21:16 — with GitHub Actions Inactive

zanieb requested review from BurntSushi and charliermarsh July 29, 2025 17:14

BurntSushi approved these changes Jul 29, 2025

View reviewed changes

charliermarsh reviewed Aug 1, 2025

View reviewed changes

Review

92f7621

charliermarsh approved these changes Aug 4, 2025

View reviewed changes

zanieb added 2 commits August 5, 2025 14:49

Merge branch 'main' into zb/package-conflicts

4e0d0ce

Merge branch 'main' into zb/package-conflicts

3c63ddd

zanieb added the preview Experimental behavior label Aug 7, 2025

zanieb changed the title ~~Add support for package-level conflicts~~ Add support for package-level conflicts in workspaces Aug 7, 2025

zanieb temporarily deployed to uv-test-registries August 7, 2025 14:04 — with GitHub Actions Inactive

Merge branch 'main' into zb/package-conflicts

9f23e5f

zanieb force-pushed the zb/package-conflicts branch from 39f6ac4 to 9f23e5f Compare August 8, 2025 12:13

zanieb temporarily deployed to uv-test-registries August 8, 2025 12:16 — with GitHub Actions Inactive

zanieb merged commit 8f71d23 into main Aug 8, 2025
95 checks passed

zanieb deleted the zb/package-conflicts branch August 8, 2025 12:45

BrewTestBot mentioned this pull request Aug 8, 2025

uv 0.8.7 Homebrew/homebrew-core#232884

Merged

+                  ");
+                  Ok(())
+              }

	if !packages.contains(item.package()) {
	// Ignore items that are not in the install targets
	continue;
	}

	// We should not filter entire projects unless they're a top-level dependency
	// Otherwise, we'll fail to solve for children of the project, like extras
	ConflictKindRef::Project => {
	if dep.parent.is_some() {
	return true;
	}
	}

Conversation

zanieb commented Jul 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

BurntSushi left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zanieb Jul 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

zanieb commented Jul 25, 2025 •

edited

Loading

zanieb Jul 29, 2025 •

edited

Loading