Add support for declarative tool installations (e.g., like Brewfile)

[michaeltinsley]

Summary

It would be great if uv had a way to store all installed tool installations into a standard file, similar to a homebrew brewfile.

My use case is I want to have tools installed with uv tool install ... added to a config file that I can track in git along with my brew installed libs in a brewfile, and my other dotfiles.

Example

No response

[zanieb]

Yeah; this is on the roadmap, though it's not a high priority right now.

[itcarroll]

@michaeltinsley Would you be okay with using pyproject.toml for this (see my near duplicate at #13268) or do you need to keep this separate from any project?

[michaeltinsley]

@itcarroll - I think a pyproject.toml would work for my use case. I could dump that in ~/.config/uv/pyproject.toml.

For my ideal workflow, I would have something like:

# ~/.config/uv/pyproject.toml
[dependency-groups]
tools = [
    "ruff",
]

which would give something like:

> uv tool list
ruff v0.11.8
- ruff

Then if I do uv tool add black, it would automatically add it

> cat ~/.config/uv/pyproject.toml
...
[dependency-groups]
tools = [
    "ruff",
    "black",
]

That would be my ideal flow - I guess I'm more interested in uv tool add ... being automatically persisted to a file than anything, if that makes sense

[codethief]

@michaeltinsley While I agree that pyproject.toml would be the appropriate place to persist tools, I'm not sure about filing them under [dependency-groups]. Keep in mind that each tool is meant to live in a separate venv, so they are somewhat different from other dependencies.

[itcarroll]

@codethief The [dependency-groups] table doesn't have any requirement that all packages listed in a group be installed in one environment, does it? Using a shared location for the list of tools seems better to me than putting it somewhere under [tools.uv]. Eventually pipx might pick up the behavior of installing tools from a given dependency group, for instance.

[rabader]

If I could chime in, it'd be great if we could also specify if it is implied that with a "uv sync" command, "uv tool sync" runs first. In a project that requires the keyrings tool today, my environment fails to install/sync unless I have first installed those tools with:

uv tool install keyring --with keyrings.google-artifactregistry-auth

Even if those packages are defined as dependencies, "uv sync" fails unless I first have those tools installed in a separate command. It'd be nice to be able to define that in the pyproject.toml file. Unless there's already a way to do that and I just missed it.

[amardeep]

My usecase is also similar.

I am working in a monorepo, with no top level pyproject.toml as of now. I would like to declaratively configure tools required for the project - for eg. sqlmesh / dbt / sqlfluff etc. These should be version locked, so other team members working on the project get the exactly same versions. At the same time, I don't want to be forced to activate a virtual environment, as it is a monorepo, and a developer would mostly we working in another virtual environment related to his work.

Ideally, I would like:

• Declarative config for monorepo tools that can be checked in as part of the monorepo
• No venv activation needed to use the tools
• Tools get installed in some bin directory, which developers can add to their path (or use direnv to add it)
• Tools remain in sync. For eg if i pull latest main branch, where the lockfile has changed, uv automatically updates the installed version
• Tools can be invoked directly, without requiring to use something like "uv run"

[codethief]

@amardeep My use case is very similar to yours; however, now that you spelled out your ideal solution, to me it sounds very much like what mise already provides. In fact, mise can already install tools from pip packages using uv, provided that uv is installed globally, see https://mise.jdx.dev/dev-tools/backends/pipx.html (in particular, the section on the pipx.uvx setting).

Of course there is something to be said about uv providing everything out of the box and not having to install mise separately. Then again, even in a monorepo with only Python projects it might very well be that people want to use tools not written in Python / not available as pip package. In other words: In an ideal world, uv would provide similar features as mise. Maybe it would make sense for uv & mise to collaborate on this topic instead of uv reinventing the wheel? (FWIW, mise already integrates quite well with uv.)

[amardeep]

Thank you for the mise recommendation @codethief. It does look like it might support my use case.