Close #9871: add uv self uninstall command

[loic-lescoat]

Summary

Close #9871: add uv self uninstall command

Mimics behavior listed on uv's official uninstallation instructions

Test Plan

How was this tested?

This was tested manually on Linux as follows: I intend to replace this with an automatic test in the .github/workflows/ci.yml file.

I ran cargo build, then:
I placed the following content into test-linux-Dockerfile

FROM ubuntu:24.04

RUN apt update
RUN apt install -y curl
RUN curl -LsSf https://astral.sh/uv/install.sh | sh

COPY target/debug/uv .
CMD bash

then started the container using:

docker build -t test-linux -f test-linux-Dockerfile . && docker run -it test-linux

Once inside the container, I ran the uninstall command
on empty directories to make sure the command succeeds:

$ /uv self uninstall --remove-data
No cache found at: /root/.cache/uv
$ echo $?
0
$ ls $HOME/.local/bin
env  env.fish
$ ls $HOME/.local/share
ls: cannot access '/root/.local/share': No such file or directory
$ ls $HOME/.local/
bin

I also tried calling uv run python and uv tool run at least once
so that the uv tool dir and uv python dir are emptied by uv self uninstall --remove-data

$ /uv run python -c 'print("hi")'
Python 3.13.2 (main, Feb  5 2025, 19:11:32) [Clang 19.1.6 ] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>
$ uv tool run jupyter --version
$ ls `/uv tool dir`
$ ls -a `/uv tool dir`
.  ..  .gitignore  .lock
$ ls -a `/uv python dir`
.  ..  .gitignore  .lock  .temp  cpython-3.13.2-linux-x86_64-gnu
$ ls -a `/uv cache dir`
.  ..  .gitignore  CACHEDIR.TAG  archive-v0  builds-v0  environments-v2  interpreter-v4  sdists-v7  sdists-v8  simple-v15  wheels-v4
$ /uv self uninstall --remove-data
Clearing cache at: /root/.cache/uv
Removed 18176 files (408.0MiB)
$ ls -a `/uv tool dir`
ls: cannot access '/root/.local/share/uv/tools': No such file or directory
$ ls -a `/uv python dir`
ls: cannot access '/root/.local/share/uv/python': No such file or directory
$ ls -a `/uv cache dir`
ls: cannot access '/root/.cache/uv': No such file or directory

[zanieb]

We use fs_err instead of std::fs for better error messages.

[zanieb]

Cool, thanks for contributing!

I'm not really sure how we'd write unit tests for this, but we can test it in CI, e.g., in the smoke-test-linux job in ci.yml

[zanieb]

I wonder if we should require the uv installer to have been used to enable this? Like we do in self_update

If so, that'd give us another way to determine the canonical install path.

[loic-lescoat]

Good point. Is it fair to say that the uv installer was used iff uv was built with the self-update feature? In other words, is it reasonable to enable the uv self uninstall command iff the uv self update command is enabled?

Thanks.

[zanieb]

I think you can check for a receipt like the update command does.

is it reasonable to enable the uv self uninstall command iff the uv self update command is enabled?

This also makes sense to me.

[loic-lescoat]

TODO:

• Relax assumption that binaries are in .local/bin
• Prototype test of this feature in smoke-test-linux job in ci.yml
• Evaluate whether we should require the uv installer to have been used to use uv self uninstall

@zanieb , instead of using std::fs, in a057630 I used rm_rf which ultimately calls fs_err. Is this OK?

Thanks for your input. I'll address these items soon

[loic-lescoat]

@zanieb as of d4965af I added a smoke test which runs self-uninstall in ci.yml; this fails because the binary is built (e.g. here) using cargo build rather than using cargo build --features self-update.

Which would you prefer?

1. Change the build from cargo build to cargo build --features self-update
2. Add a separate build process, that runs cargo build --features self-update

On the one hand, option 1. is an easier, less verbose fix and option 2. will lengthen the actions file and increase the number of Github actions.

On the other hand, the binary built using cargo build is used by other unrelated tests, e.g. integration tests