uv x as alternative to uvx

[chrisrodrigue]

Proposal

uv currently ships two different binaries with each release, uv and uvx. According to the documentation, uvx is an alias for uv tool run and the two commands are exactly equivalent. The uvx binary appears to be implemented as an executable shim.

I would like to propose that uv x be provided in place of (or in addition to) uvx.

Rationale

Precedence for this has been set with uv v which is an alias for uv venv.

C:\Users\Chris>uv
error: 'uv' requires a subcommand but one was not provided
  [subcommands: run, init, add, remove, sync, lock, export, tree, tool, python, pip, venv, virtualenv, v, build, publish, build-backend, cache, self, clean, version, generate-shell-completion, --generate-shell-completion, help]

Usage: uv [OPTIONS] <COMMAND>

For more information, try '--help'.

Pros

Removal of the shim would simplify the build and installation of uv and marginally reduce the size of the release assets (~150 KB for the x64 Windows archive).

Cons

A single Space

Example

C:\Users\Chris>uv x
Provide a command to run with `uv x <command>`.

See `uv x --help` for more information.

[zanieb]

It seems very unlikely that we would remove the uvx binary as it would be a disruptive breaking change — I don't see a compelling reason. It seems fine to provide uv x as another alias, but it's just more for people to get confused about.

[chrisrodrigue]

That's a fair point... although I would be surprised if many users have opted for uvx over the more explicit uv tool run in scripted workflows. Users preferring the uvx alias could just add it to their .bashrc or make their own uvx.cmd shim in .local\bin

(Also, the change would only be breaking if the installation script explicitly removed the shim from the previous uv release. The shim should theoretically work forever right?)

[zanieb]

I would be surprised if many users have opted for uvx over the more explicit uv tool run in scripted workflows.

I don't think I've seen much evidence of this. I see uvx used pretty widely.

(Also, the change would only be breaking if the installation script explicitly removed the shim from the previous uv release. The shim should theoretically work forever right?)

It'd be breaking for people using uv in ephemeral environments, like CI or containers.

[zanieb]

I feel like I might be doing something wrong, but

• https://github.com/search?q=%22uv+tool+run%22&type=code — 1K files
• https://github.com/search?q=%22uvx+%22&type=code — 21K files

(Without a trailing space, the second is 4M files with a lot of false positives)

[chrisrodrigue]

oof... yeah, this could be a painful change. So much for line 2 of the Zen!

You guys have been very good about not having many breaking changes. I would hate to see an influx of issues and bad PR as a result of something silly like this.

[jromal]

Users preferring the uvx alias could just add it to their .bashrc or make their own uvx.cmd shim in .local\bin

Windows exists. And in a professional environment is the most used OS.

UV is there to make the life of people easier. Not to make them create their own uvx.cmd command. You can create your own command and implement your way of work if you want.

Your assumptions on how people use uvx give me the impression that you do not use it or have explained someone else, that is not a techie, how to use it.

Not to mention that I would stop using it if a subcommand called x gets such a preferente treatment. I boycott everything named x.

[chrisrodrigue]

Your assumptions on how people use uvx give me the impression that you do not use it or have explained someone else, that is not a techie, how to use it.

I explicitly list tools as development dependencies in pyproject.toml and install them in the virtual environment of my project.

uvx seems like an homage to pipx and npx. But I would argue that the intent of uvx is less clear. From the documentation:

Running tools

The uvx command invokes a tool without installing it.

But then just a few lines down, it says

Tools are installed into temporary, isolated environments when using uvx.

Either a tool is installed or it is not. Which is it?

Clearly, tools are installed somewhere, but where? Will this abstract location just grow in size forever with tools that I tried out a single time? Why would I want this?

To me, this seems like a package management anti-pattern. But it is here to stay, since removing it would be breaking.