Better default for uv sync

[xixixao]

Summary

I'm setting up a monorepo for my team. The main command that my team members have to run is:

uv sync --all-packages --all-extras --all-groups

That's quite a mouthful. Either:

1. Could we make this the default? (that might be hard when other options are desired)
2. Make the default configurable in uv.toml? (seems that right now only uv pip can be configured?)

Example

No response

[zanieb]

We allow configuring the default-groups. You can define a dependency group that adds your project with all of your extras.

I'm not sure about the --all-packages bit, seems reasonable to have an option for that though, e.g., default-packages or default-workspace-members or something. Hm.

[konstin]

default-packages packages makes sense to me; I think the reason it hasn't come up much yet is that most projects have a main package that depends on the other packages, so that they implicitly get a correct default.

[bschoenmaeckers]

What is currently the default set of workspace packages that are installed when not specifying --all-packages?

[zanieb]

The dependencies of the main package — perhaps you want to add the other workspace members as dependencies?

[matthewadams]

You might be interested in #10960

[xixixao]

@zanieb I tried to set things up purely via adding the workspace members as dependencies to the main package, but one issue is that the workspace members' dev dependency groups are not installed.

[zanieb]

Yeah, if you have development requirements for the workspace we'd expect them to be there not in a child project. Can you share more about why you need that?

[xixixao]

Many workspace member projects, and some of the dev dependencies are specific to that project. It's not a requirement, it's more for organization.

[rsyring]

Using mise tasks, your users could just run mise uv-sync where the uv-sync script would just be uv sync --all-packages --all-extras --all-groups.

The benefit being that, if uv or the monorepo layout/commands change in the future, you can just update the task script. All the devs can keep using mise uv-sync which has no doubt become reflexive for them.

[johnthagen]

I wanted to voice my support for --all-groups being the default for uv sync. We are looking to migrate from Poetry, Poetry does this, and I've always thought it provided the smoothest, least-surprising experience. We've already had several new team members be surprised that they added some dependencies in a dependency group and they showed up in the lock file, but are not installed with uv sync by default.

We split up our development dependencies into nicely named groups. This not only is self documenting, but it allows tools like tox/nox to install only a subset of the dependencies easily into isolated virtual environments.

[dependency-groups]
nox = [
    "nox-poetry"
]
test = [
    "pytest",
    "pytest-cov",
    "pytest-randomly"
]
type_check = [
    "mypy"
]
lint = [
    "ruff"
]
docs = [
    "mkdocs-material",
    "mkdocs-htmlproofer-plugin"
]

After reading the docs, a user can learn that the dev group is special and you can extend the config with:

[tool.uv]
default-groups = ["nox", "test", "type_check", "lint", "docs"]

But this seems like extra boilerplate in my opinion and suffers from DRY risk of the names getting out of sync (and then dependencies silently not being installed). Given that --only-group and --no-group exist, to me the least surprising thing would be for uv sync to install everything by default and then allow a user to opt back out when needed.

The special cases of dev also seems strange now that we have agnostic dependency group names. I could see it making sense back when uv had to provide it's legacy

[tool.uv]
dev-dependencies = [
  "pytest"
]

But now-adays I think moving forward it would be ideal if dev wasn't special and all groups were installed by default.

[rsyring]

Related: #11691

We also use groups for the precise reason of being able to specify which dependencies I want in tox/nox. But we just use includes in the dev group so that the default install gets all the installed deps:

dev = [
    {include-group = "tests"},
    {include-group = "pre-commit"},
    {include-group = "nox"},
    "hatch>=1.14.0",
    "ruff>=0.9.6",
]
# Used by nox
pre-commit = [
    'pre-commit>=4.1.0',
    'pre-commit-uv>=4.1.4',
]
# Used by nox
tests = [
    'pytest>=8.3.4',
]
# Used by CI
nox = [
    'nox>=2025.2.9',
]

FWIW, I don't think --all-groups makes as much sense as a default when you can easily use includes to make your default dev environment use whatever groups you want.

Not sure what I think on special casing for the dev group. I like that it's a simpler CLI interface when adding deps from the command line. It also matches other dependency management tools. But having the --dev concept as a special case of default groups does bring some confusion IMO and gives extra command line arguments as a result. I'd probably leave --dev as a special case, although I would change some things as discussed in #11691.

[zanieb]

I'd be more in favor of adding a special "all" key to default-groups (e.g., default-groups = list[str] | literal["all"]) than changing the default here. I think, as we don't sync all optional-dependencies by default, it'd feel surprising to sync all dependency-groups by default.

[johnthagen]

I'd be more in favor of adding a special "all" key

I like this.

That would be sufficient for the needs I've seen. It would be explicit and also remove the DRY issues that currently exist with duplicating group names.

[zanieb]

cc @Gankra curious for your thoughts