uv pipx {run,install}

[konstin]

pipx is the preferred way to install python tools globally, storing each tool in an isolated, managed environment instead of causing problem in the global or user local environment.

We have all the basic parts required for pipx (venv creation, resolution, installation). What uv pipx would need to do is create a venv in a uv subfolder of the user data dir, install the requested package and expose the entrypoints/scripts to .local/bin or platform equivalent. We can extend this to arbitrary standard of pipx compatibility with options such as upgrade, reinstall, extend, etc.

[mqudsi]

This would be really cool.

fwiw, I found it misleading that the release announcement said uv is a full drop-in replacement for pipx (by name).. but it's not?

[BurntSushi]

This would be really cool.

fwiw, I found it misleading that the release announcement said uv is a full drop-in replacement for pipx (by name).. but it's not?

Not pipx. pip.

[mqudsi]

Just double-checked. I mistook the part about "imagine a tool that replaces" for the "this is a tool that replaces".

Mea culpa!

[johnthagen]

This would be a great way to provide an equivalent to cargo install within uv. 👍

Related to this would be PEP 723 support (inline script metadata), which pipx run also provides.

• https://pipx.pypa.io/stable/changelog/#142
• fix: use modern PEP 723 syntax, fix mistake in name pypa/pipx#1180

Related to

• A uv run subcommand #1207

[pfmoore]

Can we make the command uv run, and not uv pipx run? The convention of using uv <some command we're trying to emulate> as a subcommand seems like a bad approach long-term:

1. It either causes confusion for users, or it locks uv into matching the design of the original command, warts and all.
2. It creates a "competitive" impression, rather than a "co-operative" one.
3. Should uv become dominant, and the original command get abandoned, the subcommand name will no longer make any sense.

[astrojuanlu]

Related: #1657

[johnthagen]

The convention of using uv <some command we're trying to emulate> as a subcommand seems like a bad approach long-term:

From hearing Charlie talk about the current design of uv, the reason for this is so that uv can easily slot into existing workflows today, and at the same time provides Astal with a concrete set of features by which they can get all of the lower level machinery re-implemented in Rust. They did this with Ruff to pretty great effect.

I think there is a certain wisdom in this, since it allows them to keep the top level uv ___ open so they can get a lot of experience in the lower level internals before really stretching for ultimate goal of providing a Cargo/rustup-like experience for Python.

[konstin]

I want to keep the uv run name for running in-project scripts, i'm thinking about using something like uv install <tool> and uv runx <tool> or uv tool <tool> for pipx/npx-like global tools.

It either causes confusion for users, or it locks uv into matching the design of the original command, warts and all.

Can you talk a bit about what warts you wouldn't want us to emulate? We normally aim to be very similar to provide easier migration, so it's helpful to know where we should deviate.

[pfmoore]

Can you talk a bit about what warts you wouldn't want us to emulate?

Off the top of my head:

• The design of --target, and the way it looks like a variant on a normal install, but doesn't act like one in practice (upgrades don't work as expected, uninstall isn't supported, list doesn't work, etc). Supporting the use case(s) is important, but the command design sucks.
• Similarly, the mess of --prefer-binary vs --only-binary vs --no-binary, and the debate about making --only-binary :all: the default. Getting this right from the start rather than inheriting pip's baggage would be far better.
• Keyring and authentication support. There's lots of problems with how pip does authentication, and the way keyring is supported is a mess of tentative part solutions, caused almost entirely by the fact that keyring itself isn't a pure Python dependency so we couldn't vendor it.
• Passing of pip options to the installation of dependencies in the isolated build environment is a bit of a mess, which largely just grew out of fixing bugs as they came up. Having a proper design for how the user can configure the way installs to the build environment work would be much better.
• All of the --root, --prefix and --implementation/--abi/--platform flags, intended to make preparing an installation to be copied to "another" Python, are (IMO) far too complex, and require a deep understanding from the user to be able to use them correctly.

There's also the warts you've already chosen not to match pip over - --resolution and --pre-release spring to mind, as well as the way you treat --extra-index-url. It's hard to take seriously the idea that you prefer to emulate pip's interface "warts and all" when these examples show that it's actually only "the warts we don't want to fix"...

[samypr100]

Thanks @pfmoore, this is a very useful list. Always good to know what alternative approaches would've been better in hindsight.

[zanieb]

I'm going to close this in favor of the more accurate tracking issue at #3560. Regardless, I'll report back here when there's significant progress as I know there are a lot of subscribers to this issue.