Support `uv tool install package@version` to match `uvx`
Otherwise, going from uvx to uv tool install can be surprising.
I wonder whether using @ is appropriate over package==version. The @ is documented for example here for uv pip install "ruff @ ./projects/ruff".
package==version does work here already. But uvx uses package@version because it does not accept an arbitrary version specifier, just a single version, and we want to disambiguate.
@ is very commonly used for specifying locations/paths, for example [email protected] or package@path/to/pkg/src.
Maybe this could cause some confusion/surprises.
It might not be worth it, but... I'm not sure if it's that common? We had a lot of complaints about requiring package @ path and I'm not sure how person@company applies? Regardless, we can easily:
- Tell if it's a path and/or
- Treat it as we would now if it's not a valid PEP 440 version β that's what we do in
uvx tool@version
Ah sorry, I should have clarified that [email protected] is an email address π
Iβm not sure what PEPs might govern tokens used in the context of package paths/versions but RFC 3986 could be a good standard to reference that covers allowed uses of @ in URIs if there isnβt anything more relevant.
To be clear β we already support uvx [email protected] and uvx ruff@latest so we already have clear semantics around this. This issue is about extending those semantics to uv tool install to avoid confusion.
That makes sense π
(By the way, it looks like PEP 440 covers @ for direct references with explicit URLs.)
Gonna do this now.
This would also make sense given the docs indicate that the @ is the method for doing the install.
The name of the command can include an exact version in the format
@ , e.g., uv run [email protected]. If more complex version specification is desired or if the command is provided by a different package, use --from.
(Separately, there's a typo there, it should be uv tool run [email protected].)