Respect tool upgrades in uv tool install
#4736
Conversation
charliermarsh
changed the title
uv tool install
|
|
||
| ----- stderr ----- | ||
| warning: `uv tool install` is experimental and may change without warning. | ||
| Installed: black, blackd |
There was a problem hiding this comment.
This is a behavior change but I personally think it's ok to copy over the entrypoints even on a no-op. I could probably figure out a way to avoid this as an optimization though.
There was a problem hiding this comment.
I agree it's "okay" but it feels a little weird to me.
There was a problem hiding this comment.
I think it's safer and simpler to copy them over every time, avoids any weird issues around trying to detect if the package changed in the environment or the entrypoints getting out-of-sync with the environment.
| let environment = installed_tools.environment( | ||
| &name, | ||
| // Do not remove the existing environment if we're reinstalling a subset of packages | ||
| !matches!(settings.reinstall, Reinstall::Packages(_)), |
There was a problem hiding this comment.
It seems ok to me to only remove this when --force is provided?
There was a problem hiding this comment.
In other words: can't we defer to our underlying virtualenv update machinery to manage this by reinstalling packages as required?
|
Don't understand the dreaded Windows failures yet but I'll look at them once approved. |
| interpreter, | ||
| cache, | ||
| )?; | ||
| let environment = installed_tools.environment(&name, force, interpreter, cache)?; |
There was a problem hiding this comment.
I don't think force needs to imply deletion of the environment though? This seems a little weird. I think we should only remove the existing environment if the requested Python interpreter is different.
There was a problem hiding this comment.
We can do that… I feel like force is sorta useful too personally.
There was a problem hiding this comment.
Force would be like: completely ignore whatever already exists.
There was a problem hiding this comment.
Hm. It feels weird to mix the purpose for me. I agree removing the environment sounds useful but in what case would someone actually need to do that?
There was a problem hiding this comment.
(it seems safe to discuss and address this separately from this pull request)
There was a problem hiding this comment.
I guess if the environment was broken and the receipt was out-of-sync, even uninstall wouldn't remove it...? Maybe I'll change uninstall to handle that edge case, then remove this.
There was a problem hiding this comment.
If the environment is broken then --force totally could / should remove it.
There was a problem hiding this comment.
Maybe: if there's no receipt, and the environment exists, we remove it? :)
charliermarsh
force-pushed
the
charlie/tool-upgrade
branch
from
c53dc5b
to
fa239ea
Compare
charliermarsh
force-pushed
the
charlie/tool-upgrade
branch
from
773bd2e
to
2a8c8c6
Compare
charliermarsh
force-pushed
the
charlie/tool-upgrade
branch
from
2a8c8c6
to
270f068
Compare
Summary
For now the semantics are such that if the requested requirements from the command line don't match the receipt (or if any
--reinstallor--upgradeis requested), we proceed with an install, passing the--reinstalland--upgradeto the underlying Python environment.This may lead to some unintuitive behaviors, but it's simplest for now. For example:
uv tool install black<24followed byuv tool install black --upgradewill install the latest version ofblack, removing the<24constraint.uv tool install black --with black-pluginfollowed byuv tool install blackwill removeblack-plugin.Closes #4659.