Should `uvx` use a project dependency if available?

[zanieb]

Right now, uvx will run in an isolated environment even if the target tool is installed in the current project. For example, uvx ruff will not use the version of Ruff declared in the project (e.g., with uv add ruff==0.3.0). If we're in a project, it might make sense to respect the version there instead of ignoring it?

This may be a reasonable way to support defining tools in projects until we design and implement "project-level tool definitions" per #3560.

Related:

• https://github.com/astral-sh/uv/issues/6377
• https://github.com/astral-sh/uv/issues/5903#issuecomment-2336546258

• 3560

[helderco]

My preference is to reserve uvx for stuff in .venv/bin (like npx) since uv tool install ruff can create symlinks for the tool's binaries in a place that can be added to the $PATH (like pipx) and run with simply ruff.

[zanieb]

My preference would be to use uv tool run, but place symlinks for the tools in a directory that can be added to the $PATH

Isn't this just uv tool install?

That way, I could install ruff globally with uv tool install ruff, run it with just ruff check, and use uvx for stuff in .venv/bin (like npx with node_modules/bin).

Except npx will also run arbitrary versions without installing them, right? I'm not sure I follow.

[helderco]

Sorry, I'm on my phone so I can't try things. Reworded my previous comment right after posting.

Didn't know npx could run commands without installing. I don't personally use it now but did a few years ago, when npx came out it was used just for easily running installed binaries in the project.

For global installations I rather use the $PATH. I do use uv run a lot and would prefer uvx be used to shorten that. As for running without installing, could uvx try these in turn?

• in .venv
• in tools dir
• isolated

[zanieb]

Yep that's the suggestion this issue tracks.

[inoa-jboliveira]

Currently uvx is really just a shorthand for uv tool run but it could be a more intelligent command using context.

Meaning it will either call uv run or uv tool run as necessary. And if you actually mean one or the other, you could force it by using the explicit form. If you bake "run" inside "tool run", you lose this ability.

I don't know if that is feasible as these commands have different options. My original suggestion was to have a 3rd command but I am seeing it as more confusing to the end user than a smarter uvx

[zanieb]

The idea here is that uv tool run would check the project for the dependency too. You'd use --no-project to ignore the project dependency declaration. I don't think uvx will ever have different semantics than uv tool run (it'd be too confusing).