-
Notifications
You must be signed in to change notification settings - Fork 900
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add uv tool install
#4492
Add uv tool install
#4492
Conversation
4358b81
to
502c1da
Compare
db4e62d
to
5bfdbbe
Compare
3967fe7
to
ceec118
Compare
Nice to have for #4492 and seems like a good idea in general to avoid mutating a developer's machine.
de0c954
to
49d3532
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A single tools.toml
for all tools sounds like a way that could break all installed tool by corrupting a single file, what e.g. about $UV_STATE_DIR/tools/$name/tool.toml
for each tool?
Should we add versioning to the toml file(s) to allow breaking changes in the format?
We should add locking to prevent concurrent modification of both tools and toml files; we already have an abstraction for this with LockedFile::acquire(tool_dir.join(".lock"), tool_dir.user_display())
.
Seems reasonable, though I wanted a central file for bulk operations. I guess we can read every directory instead pretty easily. It won't break the tools though it'd just stop you from installing more.
Perhaps eventually, but it doesn't seem critical right now. Do you think we need to immediately?
Sounds good to me. |
I'd put a |
I'm hesitating on multiple |
I'm going to skip adding a version in this pull request, but I'm happy to do it next. I just want to think more carefully about how it works. |
) While working on #4492 I noticed that `--reinstall-package` was not actually respected by `update_environment`, it exited early due to satisfied requirements. Before ``` ❯ cargo run -q -- tool install black -v --reinstall-package tomli ... DEBUG All requirements satisfied: black | click>=8.0.0 | mypy-extensions>=0.4.3 | packaging>=22.0 | pathspec>=0.9.0 | platformdirs>=2 | tomli>=1.1.0 ; python_version < '3.11' | typing-extensions>=4.0.1 ; python_version < '3.11' ``` After ``` ❯ cargo run -q -- tool install black -v --reinstall-package tomli ... Uninstalled 1 package in 0.99ms Installed 1 package in 4ms - tomli==2.0.1 + tomli==2.0.1 ```
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! My only concern here is around tools.toml
, because it feels under-explored right now and (as far as I can tell) is unused at the moment. Will we always keep it in sync? What are the motivating use-cases?
Rock on |
Refactors the installed tool metadata per commentary in #4492 We now store a `uv-receipt.toml` per tool install instead of a single `tools.toml`
This is the minimal "working" implementation. In summary, we:
$UV_STATE_DIR/tools/$name
dist-info
for the main requirement to determine its entry points scripts$XDG_BIN_HOME
) to the environment bin$UV_STATE_DIR/tools/tools.toml
tracking the user's requestThe idea with
tools.toml
is that it allows us to perform upgrades and syncs, retaining the original user request (similar to declarations in apyproject.toml
). I imagine using a similar schema in thepyproject.toml
in the future if/when we add project-levle tools. I'm also considering exposingtools.toml
in the standard uv configuration directory instead of the state directory, but it seems nice to tuck it away for now while we iterate on it. Installing a tool won't perform a sync of other tool environments, we'll probably have an explicituv tool sync
command for that?I've split out todos into follow-up pull requests:
uv tool install
#4509 (failing on Windows)uv tool install --force
#4501--reinstall
and--reinstall-package
inuv tool install
#4504Closes #4485