Add a 5 min default timeout for deadlocks

[konstin]

When a process is running and another calls uv cache clean or uv cache prune we currently deadlock - sometimes until the CI timeout (astral-sh/setup-uv#588). To avoid this, we add a default 5 min timeout waiting for a lock. 5 min balances allowing in-progress builds to finish, especially with larger native dependencies, while also giving timely errors for deadlocks on (remote) systems.

Commit 1 is a refactoring.

This branch also fixes a problem with the logging where acquired and released resources currently mismatch:

DEBUG Acquired lock for `https://github.com/tqdm/tqdm`
DEBUG Using existing Git source `https://github.com/tqdm/tqdm`
DEBUG Released lock at `C:\Users\Konsti\AppData\Local\uv\cache\git-v0\locks\16bb813afef8edd2`

[konstin]

This should happen rarely and already involves waiting, so we can spawn a thread. I quickly looked into making it generally async but it didn't seem worth the churn.

[zanieb]

Hm, we only have a couple calls to the blocking / sync versions of the lock APIs. I'd be tempted to make them async.

I wonder if we should move this timeout handling to the API functions so we can run_with_timeout in the blocking / sync versions and just use an async timeout in the async versions? I'm wary of spawning a thread just for a timeout in the async case.

[zanieb]

It'd be nice to have this to our standard environment variable parsing in EnvironmentOptions instead, I don't want to keep adding ad-hoc parsing like this.

If you want to defer it to reduce churn, that's okay — but we should add it the tracking issue and make sure it's moved.

[konstin]

I've added it to #14720, do you want a separate tracking issue?

I had looked into parsing this centrally but the locks are called in a lot of locations including e.g. a LazyLock in a Default impl (

uv/crates/uv-auth/src/middleware.rs

Line 79 in 7f38a8a

match TextCredentialStore::read(&path) {

)

[zanieb]

We might want to say "You can set ... to increase the timeout" instead of "Set" which makes it sounds like you should do that as the solution.

[zanieb]

I think this is more complicated than it needs to be. We can just do

uv/crates/uv/tests/it/cache_clean.rs

Line 74 in 107d4e0

let _cache = uv_cache::Cache::from_path(context.cache_dir.path()).with_exclusive_lock();

[zanieb]

#16342 (comment) is my main remaining caveat.

We should probably also add a note in https://docs.astral.sh/uv/concepts/cache since that's the main place this will be relevant.

[zanieb]

On the timing, I guess I might expect something like 60s rather than 5m? 5m is nice and conservative though, we could reduce it later once we see that 5m doesn't break anything

[konstin]

That's a bit more risky change because it assumes tests do not lock or spawn something in the background and then operate on Python versions.

[konstin]

The alternative is making every integration test async

[konstin]

I rewrote it entirely async and removed the duplication between sync and async as well as shared and exclusive.

On the timing, I guess I might expect something like 60s rather than 5m? 5m is nice and conservative though, we could reduce it later once we see that 5m doesn't break anything

I can see some (e.g. Rust) build taking >60s, so I'd like to go with a higher timeout.

[konstin]

I've rebased on top of dropping fs2