Cleanup .venv on Ctrl-C interrupt during `uv sync`

[atbraz]

When running uv sync without specifying a Python version, the command automatically selects the latest compatible version based on project.requires-python. If this selected version is undesirable (e.g., Python 3.13 for projects known to have compatibility issues), the only way to stop the process is using Ctrl-C. However, this leaves behind a partially created .venv directory that must be manually cleaned up before retrying with the correct Python version.

Expected Behavior

When uv sync is interrupted with Ctrl-C, it should clean up any partially created resources, including the .venv directory, similar to the behavior implemented in #7024.

Current Behavior

Currently, interrupting uv sync with Ctrl-C leaves behind a partially created .venv directory, requiring manual cleanup before retrying with a different Python version.

Steps to Reproduce

1. Have a project with project.requires-python = ">=3.10"
2. Run uv sync without -p flag
3. Observe it selecting Python 3.13
4. Interrupt with Ctrl-C
5. .venv directory remains, requiring manual deletion

Example

ai on  main is 📦 v0.1.1 via 🐍 v3.11.2 took 4s
z ➜  uv sync
Using CPython 3.13.0
Creating virtual environment at: .venv
⠼ Resolving dependencies...                                                                                                                                                                   ^C

ai on  main is 📦 v0.1.1 via 🐍 v3.11.2
z ➜  l
Permissions Size User  Date Modified Git Repo   Name
drwxr-xr-x     - abraz 4 days         -I | main  .git/
drwxr-xr-x     - abraz 4 seconds      -I - -     .venv/
drwxr-xr-x     - abraz 5 days         -- - -     docs/
drwxr-xr-x     - abraz 5 days         -- - -     pkgs/
drwxr-xr-x     - abraz 5 days         -- - -     requirements/
drwxr-xr-x     - abraz 5 days         -- - -     scripts/
drwxr-xr-x     - abraz 5 days         -- - -     tests/
.rw-r--r--  2.0k abraz 5 days         -- - -     .gitignore
.rw-r--r--     0 abraz 4 days         -- - -     CHANGELOG.md
.rw-r--r--  2.3k abraz 4 days         -- - -     pyproject.toml
.rw-r--r--   985 abraz 5 days         -- - -     README.md
.rw-r--r--   171 abraz 4 days         -- - -     requirements.txt

ai on  main is 📦 v0.1.1 via 🐍 v3.11.2
z ➜  rm -rf .venv

ai on  main is 📦 v0.1.1 via 🐍 v3.11.2
z ➜  uv sync -p 3.10
Using CPython 3.10.15
Creating virtual environment at: .venv
⠦ Resolving dependencies... 
...

Environment

• uv: 0.5.1
• OS: Debian GNU/Linux 12 (bookworm) on Windows 10 x86_64
• Kernel: 5.15.167.4-microsoft-standard-WSL2

Related Issues

#7024 (Similar cleanup behavior)

Proposed Solution

Implement cleanup of the .venv directory and any other temporary resources when uv sync is interrupted with Ctrl-C, similar to other cleanup behaviors in the codebase.

Verbose Logs

$ uv sync --verbose
DEBUG uv 0.5.1
DEBUG Found project root: `/home/abraz/dev/ai`
DEBUG No workspace root found, using project root
DEBUG Using Python request `>=3.10` from `requires-python` metadata
DEBUG Searching for Python >=3.10 in managed installations or search path
DEBUG Searching for managed installations at `/home/abraz/.local/share/uv/python`
DEBUG Found managed installation `cpython-3.13.0-linux-x86_64-gnu`
DEBUG Found `cpython-3.13.0-linux-x86_64-gnu` at `/home/abraz/.local/share/uv/python/cpython-3.13.0-linux-x86_64-gnu/bin/python3.13` (managed installations)
Using CPython 3.13.0
Creating virtual environment at: .venv
DEBUG Using request timeout of 30s
DEBUG No static `pyproject.toml` available for: abs-ai @ file:///home/abraz/dev/ai (PyprojectToml(DynamicField("dependencies")))
DEBUG Acquired lock for `/home/abraz/.cache/uv/sdists-v6/editable/5cc2d4d098a11eee`
DEBUG Using cached metadata for: abs-ai @ file:///home/abraz/dev/ai
DEBUG No workspace root found, using project root
DEBUG Released lock at `/home/abraz/.cache/uv/sdists-v6/editable/5cc2d4d098a11eee/.lock`
DEBUG Solving with installed Python version: 3.13.0
DEBUG Solving with target Python version: >=3.10
...

[charliermarsh]

I'm unsure... If you use uv sync --python 3.10, it should delete and recreate the venv for you?

[atbraz]

uv sync --python 3.10 does solve the example I described wonderfully. My concern has more to do with the behaviour of Ctrl-cing while running uv sync in any situation. I imagine that it would be tidier to revert all the modifications made to the local environment when stopping the execution of the command

[zanieb]

Why does the virtual environment need to be manually deleted? A subsequent operation just deletes it right?

I don't think it's feasible for us to always clean up state on interrupt. The point of having declarative state in a lockfile is that it's trivial to re-sync the environment — we can treat them as disposable.

[zkurtz]

One related issue I've encountered is that any kind of uv sync crash can leave behind random-named tmp files in .venv, triggering antivirus software, potentially leading to interference from the corporate SOC. So even if we don't delete .venv, having a cleaner state at the end of a crash could be really valuable. I don't know if those tmp files are something that uv produces explicitly, or they could come from lower-level calls?