uv sync always tries to resolve all optional-dependencies

[chrisjsewell]

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 #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 #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 #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?