Allow conflicting optional dependencies and dependency groups #6981
Assignees
Comments
This was referenced Sep 23, 2024
|
We're currently adopting uv in our company and recently encountered this issue. I was wondering if there are any updates or timeline on when this feature might be addressed? It would be really valuable for us. Anyway, thanks for all the fantastic work on uv! |
|
We're working on this now, but we consider it a difficult / high risk problem so I'm not sure when we'll have a solution. |
This was referenced Oct 8, 2024
zanieb
added a commit
that referenced
this issue
Oct 16, 2024
… in `uv lock` (#8110) Part of #8090 Adds the ability to include a group (`--group`) in the sync or _only_ sync a group (`--only-group`). Includes all groups in the resolution, which will have the same limitations as extras as described in #6981. There's a great deal of refactoring of the "development" concept into "groups" behind the scenes that I am continuing to defer here to minimize the diff. Additionally, this does not yet resolve interactions with the existing `dev` group — we'll tackle that separately as well. I probably won't merge the stack until that design is resolved. The current proposal is that we'll just "combine' the `dev-dependencies` contents into the `dev` group.
zanieb
added a commit
that referenced
this issue
Oct 18, 2024
… in `uv lock` (#8110) Part of #8090 Adds the ability to include a group (`--group`) in the sync or _only_ sync a group (`--only-group`). Includes all groups in the resolution, which will have the same limitations as extras as described in #6981. There's a great deal of refactoring of the "development" concept into "groups" behind the scenes that I am continuing to defer here to minimize the diff. Additionally, this does not yet resolve interactions with the existing `dev` group — we'll tackle that separately as well. I probably won't merge the stack until that design is resolved. The current proposal is that we'll just "combine' the `dev-dependencies` contents into the `dev` group.
charliermarsh
pushed a commit
that referenced
this issue
Oct 20, 2024
… in `uv lock` (#8110) Part of #8090 Adds the ability to include a group (`--group`) in the sync or _only_ sync a group (`--only-group`). Includes all groups in the resolution, which will have the same limitations as extras as described in #6981. There's a great deal of refactoring of the "development" concept into "groups" behind the scenes that I am continuing to defer here to minimize the diff. Additionally, this does not yet resolve interactions with the existing `dev` group — we'll tackle that separately as well. I probably won't merge the stack until that design is resolved. The current proposal is that we'll just "combine' the `dev-dependencies` contents into the `dev` group.
charliermarsh
pushed a commit
that referenced
this issue
Oct 22, 2024
… in `uv lock` (#8110) Part of #8090 Adds the ability to include a group (`--group`) in the sync or _only_ sync a group (`--only-group`). Includes all groups in the resolution, which will have the same limitations as extras as described in #6981. There's a great deal of refactoring of the "development" concept into "groups" behind the scenes that I am continuing to defer here to minimize the diff. Additionally, this does not yet resolve interactions with the existing `dev` group — we'll tackle that separately as well. I probably won't merge the stack until that design is resolved. The current proposal is that we'll just "combine' the `dev-dependencies` contents into the `dev` group.
charliermarsh
pushed a commit
that referenced
this issue
Oct 22, 2024
… in `uv lock` (#8110) Part of #8090 Adds the ability to include a group (`--group`) in the sync or _only_ sync a group (`--only-group`). Includes all groups in the resolution, which will have the same limitations as extras as described in #6981. There's a great deal of refactoring of the "development" concept into "groups" behind the scenes that I am continuing to defer here to minimize the diff. Additionally, this does not yet resolve interactions with the existing `dev` group — we'll tackle that separately as well. I probably won't merge the stack until that design is resolved. The current proposal is that we'll just "combine' the `dev-dependencies` contents into the `dev` group.
charliermarsh
pushed a commit
that referenced
this issue
Oct 23, 2024
… in `uv lock` (#8110) Part of #8090 Adds the ability to include a group (`--group`) in the sync or _only_ sync a group (`--only-group`). Includes all groups in the resolution, which will have the same limitations as extras as described in #6981. There's a great deal of refactoring of the "development" concept into "groups" behind the scenes that I am continuing to defer here to minimize the diff. Additionally, this does not yet resolve interactions with the existing `dev` group — we'll tackle that separately as well. I probably won't merge the stack until that design is resolved. The current proposal is that we'll just "combine' the `dev-dependencies` contents into the `dev` group.
charliermarsh
pushed a commit
that referenced
this issue
Oct 25, 2024
… in `uv lock` (#8110) Part of #8090 Adds the ability to include a group (`--group`) in the sync or _only_ sync a group (`--only-group`). Includes all groups in the resolution, which will have the same limitations as extras as described in #6981. There's a great deal of refactoring of the "development" concept into "groups" behind the scenes that I am continuing to defer here to minimize the diff. Additionally, this does not yet resolve interactions with the existing `dev` group — we'll tackle that separately as well. I probably won't merge the stack until that design is resolved. The current proposal is that we'll just "combine' the `dev-dependencies` contents into the `dev` group.
zanieb
added a commit
that referenced
this issue
Oct 25, 2024
… in `uv lock` (#8110) Part of #8090 Adds the ability to include a group (`--group`) in the sync or _only_ sync a group (`--only-group`). Includes all groups in the resolution, which will have the same limitations as extras as described in #6981. There's a great deal of refactoring of the "development" concept into "groups" behind the scenes that I am continuing to defer here to minimize the diff. Additionally, this does not yet resolve interactions with the existing `dev` group — we'll tackle that separately as well. I probably won't merge the stack until that design is resolved. The current proposal is that we'll just "combine' the `dev-dependencies` contents into the `dev` group.
zanieb
changed the title
BurntSushi
added a commit
that referenced
this issue
Nov 13, 2024
This PR adds support for conflicting extras. For example, consider
some optional dependencies like this:
```toml
[project.optional-dependencies]
project1 = ["numpy==1.26.3"]
project2 = ["numpy==1.26.4"]
```
These dependency specifications are not compatible with one another.
And if you ask uv to lock these, you'll get an unresolvable error.
With this PR, you can now add this to your `pyproject.toml` to get
around this:
```toml
[tool.uv]
conflicting-groups = [
[
{ package = "project", extra = "project1" },
{ package = "project", extra = "project2" },
],
]
```
This will make the universal resolver create additional forks
internally that keep the dependencies from the `project1` and
`project2` extras separate. And we make all of this work by reporting
an error at **install** time if one tries to install with two or more
extras that have been declared as conflicting. (If we didn't do this,
it would be possible to try and install two different versions of the
same package into the same environment.)
This PR does *not* add support for conflicting **groups**, but it is
intended to add support in a follow-up PR.
Closes #6981
Fixes #8024
Ref #6729, Ref #6830
This should also hopefully unblock
dagster-io/dagster#23814, but in my testing, I
did run into other problems (specifically, with `pywin`). But it does
resolve the problem with incompatible dependencies in two different
extras once you declare `test-airflow-1` and `test-airflow-2` as
conflicting for `dagster-airflow`.
NOTE: This PR doesn't make `conflicting-groups` public yet. And in a
follow-up PR, I plan to switch the name to `conflicts` instead of
`conflicting-groups`, since it will be able to accept conflicting extras
_and_ conflicting groups.
|
@BurntSushi since this tracks dependency groups as well, I've reopened it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
A project should be able to declare mutually exclusive optional dependencies, which have conflicting requirements and are solved separately.
This problem is challenging because if any optional dependency group can be incompatible with any other group, we need to perform a resolution for every possible dependency group combination.
Note, following the recent standardization of local dependency groups, this issue includes allowing conflicts in those as well. The underlying changes that need to happen in the resolver are the same.
See also #6729
The text was updated successfully, but these errors were encountered: