`uv sync` always tries to resolve all `optional-dependencies`

[chrisjsewell]

trafficstars

the initial options of uv sync would lead me to believe that extras should not be resolved by default

$ uv sync --help       
Update the project's environment

Usage: uv sync [OPTIONS]

Options:
      --extra <EXTRA>                            Include optional dependencies from the extra group name
      --all-extras                               Include all optional dependencies

yet when I try to run it, I get e.g:

$ uv sync
× No solution found when resolving dependencies:
...
because myproject[docs] depends on projectx ...

It's weird, because if I remove projectx from the doc optional-dependencies, it works and none of the other dependencies in doc are included in the .venv

---

I see this is because uv tries to add all optional-dependencies to the uv.lock first, but what if I do not want them in there, because they have incompatibilities

[charliermarsh]

This is by design. We resolve the entire project at once, but would only install the subset that's relevant. Conflicting optional dependencies are not yet supported.

[chrisjsewell]

Conflicting optional dependencies are not yet supported

heya, yeh this is a blocker for using uv in a similar way to e.g. tox, i.e. having different optional groups, for running tests, doc builds, etc against different dependency matrices (that can potentially conflict).

I guess hopefully https://github.com/astral-sh/uv/issues/5632 should allow this one day

but for now I'll probably stick to https://github.com/tox-dev/tox-uv (which works better for this) rather than "full-blown" uv 😅

[zanieb]

We should document this in https://docs.astral.sh/uv/concepts/projects/#project-lockfile

I guess we should also have an issue specifically tracking allowing conflicting extras.

I'll follow up on these things.

[chrisjsewell]

cheers

[chrisjsewell]

To clarify, the main use case, is that I want to be able to do something like this: tox -e py38-sphinx6,py310-sphinx8, i.e. running pytest against different versions of Python, and potentially different versions of key "peer dependencies"

[arsatiki]

I was bit by this today as well, trying to sync the mlflow repository. The --help options seemed contradictory, since I was very emphatically not installing any extras and it still croaked on jfrog 😒

[zanieb]

@arsatiki what do you expect the --help output to say?

[zanieb]

Tracking support in https://github.com/astral-sh/uv/issues/6981

[arsatiki]

@zanieb I think the help texts for one or both options should mention that they are still trying to resolve all extras, even if they are not installed.

At least I do not find it intuitive that an extra would affect the resolution, unless I specifically opt into the extra. (But I get why you have chosen the opposite strategy.) Since it does the (in my view) unintuitive thing, the relevant option should notify me about it.

[zanieb]

Thanks I'll update that.

[zanieb]

See https://github.com/astral-sh/uv/pull/7013

[wimiko]

I have a variation of this problem, but not so much with conflicting extras, but rather with missing extras:

[project.optional-dependencies]
with_everything = [
    "something-extra",
]

[tool.uv.sources]
something-extra = { path = "../something_extra" }

I was hoping that I would be able to do uv run without the extras when "../something_extra" doesn't exist, but that doesn't seen to be the case:

error: Distribution not found at: file:///...

I also tried adding dependency-metadata for this package in the hope that it wouldn't try to find it, but that didn't help.

I'm guessing that the solution proposed in #8976 doesn't really help in this situation?

[lordinarynathan]

Hit this today. My use case is identical to what @wimiko posted above. I have a local something_extra project that may not always exist, and want my main project to gracefully handle this.

I intuitively expected uv sync to resolve + install all the required dependencies, and use uv sync --extra something_extra to resolve + install the optional ones. uv sync failing when optional things don't exist feels like it makes them mandatory, in a way.

Is there any way to have a truly optional, possibly nonexistent, local source dependency in uv?

[zanieb]

uv sync failing when optional things don't exist feels like it makes them mandatory, in a way.

They're only mandatory for constructing the lockfile. If you create a lockfile when it exists, you should be able to install from the lockfile when it's missing, e.g., with uv sync --frozen

[andres-ito-traversal]

I was bit by something similar today. I would like to be able to generate a uv lock file excluding a particular optional dependency group

[cottephi]

Same here : my code depends on some package on Linux, and some others on Windows. But obviously when I uv sync I can't be on both ^^

[zanieb]

Same here : my code depends on some package on Linux, and some others on Windows. But obviously when I uv sync I can't be on both ^^

Use platform markers for the dependencies, uv supports this just fine.

See

• https://docs.astral.sh/uv/concepts/projects/dependencies/#platform-specific-dependencies
• https://packaging.python.org/en/latest/specifications/dependency-specifiers/#environment-markers

[atodniAr]

Same here. My usecase is use different extra recipe for different cuda/torch/... version so users with different gpu can use my package with ease.

[konstin]

@atodniAr Did you see https://docs.astral.sh/uv/guides/integration/pytorch/?

[barseghyanartur]

There's a solution implemented recently. Declare the conflicting dependencies and uv sync works again.

See the documentation on conflicting dependencies .

[atodniAr]

@atodniAr Did you see https://docs.astral.sh/uv/guides/integration/pytorch/?

Not at the time I posted the comment. I'm using it now and it works.

[bkmi]

I have another case which does not seem to be covered by conflicts.

Imagine you have a dependency, e.g.

git submodule add problem-project
uv add problem-project

if one of the optional dependencies of problem-project is not installable, this means I cannot add that project.