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

add support for package level conflicts with groups #9130

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

BurntSushi
Copy link
Member

This PR adds support for declaring a conflict between a group
and a project's "production" dependencies. For example:

[project]
name = "example"
version = "0.1.0"
description = "Add your description here"
readme = "README.md"
requires-python = ">=3.12"
dependencies = [
    "anyio>=4.6.2.post1",
]

[dependency-groups]
foo = [
    "anyio<4.6.2.post1",
]

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

Before this PR, syntax like { package = "example" } wasn't allowed.
This PR enables that syntax, and also tweaks the forking logic a bit
to support this.

I don't have 100% confidence in this PR. In particular, I'm not sure
if my trick adding a parent package to PubGrubDependency is fully
correct. But I think it works.

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.
@zanieb
Copy link
Member

zanieb commented Nov 16, 2024

(I think the experience makes sense, not feeling confident about reviewing the implementation)

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.

3 participants