Conflicting general dependency and extra transitive dependency

[avicooper1]

Linux, Python version 3.10, uv version 0.5.4

I am trying to set up the following set of requirements in my team's project: I have dependency A for the project. I don't care what the version A is, but would strongly prefer it be the latest version. I would also occasionally like to use dependency B. Dependency B has a transitive dependency which happens to be an old version of A.

Specifically, the project depends on transformers, and I'd like to have the latest version 4.46.3. I'd occasionally like to use salesforce-lavis. However the latest version of this library depends on transformers>=4.25.0,<4.27.

My goal is to be able to run my code with transformers==4.46.3, but if I set some flag, then it would be transformers==4.26.1 (the version that gets resolved for salesforce-lavis.) For example,

$ uv run python
>>> import transformers
>>> transformers.__version__
'4.46.3'

but if I run something else, it automatically changes the version:

$ uv run --WITH_LAVIS python
>>> import transformers
>>> transformers.__version__
'4.26.1'

I have looked into using groups, optional dependancies, and extras. I'm not sure any of them solve what I am looking to do, and I'm wondering if there is any workaround.

---

The farthest I've gotten is with the following toml:

[project]
name = "uv-test"
version = "0.1.0"
description = "Add your description here"
readme = "README.md"
requires-python = ">=3.10"
dependencies = [
]

[dependency-groups]
lavis = [
    "salesforce-lavis>=1.0.2",
]
base = [
    "transformers>=4.46.3",
]

[tool.uv]
default-groups = ["base"]
conflicts = [
    [
      { group = "base" },
      { group = "lavis" },
    ],
]

now uv run python yields transformers==4.46.3 and uv run --only-group lavis python yields transformers==4.26.1.

However there are some remaining problems with this approach:

1. Ideally it would be easy to set up:

$ uv init
$ uv add transformers
$ uv add --group lavis salesforce-lavis

and the desired behavior would be achieved. However to get the above toml I needed to manually create the base group, set it to be the default, and to not conflict with the lavis group.

2. Even with this approach, it doesn't seem possible to upgrade transformers to the newest version. For example, starting with the same toml, but with an empty base dependency list, running uv add --group base transformers or uv add --group base -U transformers installs the same old version that's already being used by salesforce-lavis.

3. It doesn't seem like this approach would work if more dependencies were added outside of any group, (ie. inside dependencies = [].) I tried using uv run --group lavis python and it yields transformers==4.46.3 (which itself seems like a bug to me.) If limited to using --no-group then if there is ever a new dependency that can be used by both base and lavis, uv run --only-group lavis python will not see it.

---

If there are any workarounds to achieve what I'm hoping to, I would greatly appreciate some direction! Thank you.

[charliermarsh]

Yeah for something like this you'll need to edit the pyproject.toml manually -- it's fairly complex and I don't know that it would be easy to express in uv add even if we wanted to support it natively there.

[charliermarsh]

I think you should be able to uv lock --upgrade-package transformers to upgrade transformers from here?

[charliermarsh]

I tried using uv run --group lavis python and it yields transformers==4.46.3 (which itself seems like a bug to me.)

I think this should fail at runtime... Since it's trying to install both conflicting groups. I consider that a bug.

(Filed: #9355)

[charliermarsh]

I would expect that you need to do uv run --group lavis --no-group base python. Or remove base from default-groups.

[charliermarsh]

I guess we could consider (1) removing default groups that conflict when you specify --group lavis, or (2) disabling default groups when you specify a group explicitly at all, but both of those seem slightly off to me. \cc @zanieb on CLI

[zanieb]

Yeah I don't love the idea of automatically disabling default groups, though we could consider it if it's super common. It seems like the first step is a more helpful error message.

[fynnsu]

I am trying to set up the following set of requirements in my team's project: I have dependency A for the project. I don't care what the version A is, but would strongly prefer it be the latest version. I would also occasionally like to use dependency B. Dependency B has a transitive dependency which happens to be an old version of A.

I am also dealing with a similar issue. I have a package that depends on pytorch and I would like to always use that latest stable version when running things with uv run, etc. However, I have a github action that runs regularly and tests my package against the latest pytorch nightly version. So for that case only, I want to use a different pytorch version from a different index.

It would be great if there was a way to setup the dependencies with default versions but have the ability to override all defaults with a flag. It seems like the --with option does something similar (i.e. --with torch<2 will install torch<2 even if torch>2 is in my pyproject.toml) but only works with packages, not groups and doesn't allow me to specify a different index (uv run --with torch --index-url ... doesn't use the specified index for the --with install).

[charliermarsh]

Wait, actually: uv run --group lavis python does error? Are you seeing something different @avicooper1?

❯ uv run --group lavis python
error: group `base`, group `lavis` are incompatible with the declared conflicts: {`uv-test:base`, `uv-test:lavis`}