feat: improved msg for network timeouts

[samypr100]

Summary

Closes #1922

When a timeout occurs, it hints to the user to configure the UV_HTTP_TIMEOUT env var.

Before

error: Failed to download distributions
  Caused by: Failed to fetch wheel: torch==2.2.0 
  Caused by: Failed to extract source distribution
  Caused by: request or response body error: operation timed out
  Caused by: operation timed out

After

error: Failed to download distributions
  Caused by: Failed to fetch wheel: torch==2.2.0 
  Caused by: Failed to extract source distribution
  Caused by: Failed to download distribution due to network timeout. Try increasing UV_HTTP_TIMEOUT.

Test Plan

Wasn't sure if we'd want a test. If we do, is there a existing mechanism or preferred approach to force a timeout to occur in tests? Maybe set the timeout to 1 and add torch as an install check (although it's possible that could become flaky)?

[charliermarsh]

It looks like Zanie suggested HTTP_TIMEOUT. Do you mind changing to HTTP_TIMEOUT, and displaying the current value too? This is great!

[samypr100]

Good point, I decided to use UV_HTTP_TIMEOUT for consitency with registry_client.rs first check (which seems to prefer UV_HTTP_TIMEOUT and HTTP_TIMEOUT last). I could also update that warn_user_once as part of this PR if we want to be fully consistent.

            let timeout = env::var("UV_HTTP_TIMEOUT").or_else(|_| env::var("UV_REQUEST_TIMEOUT")).or_else(|_| env::var("HTTP_TIMEOUT")).and_then(|value| {
                value.parse::<u64>()
                    .or_else(|_| {
                        // On parse error, warn and  use the default timeout
                        warn_user_once!("Ignoring invalid value from environment for UV_REQUEST_TIMEOUT. Expected integer number of seconds, got \"{value}\".");
                        Ok(default_timeout)
                    })
            }).unwrap_or(default_timeout);

[zanieb]

I think UV_HTTP_TIMEOUT is good, it seems better not to recommend changing a value that other clients will respect unless you need to.

[zanieb]

Can we say how long the timeout is currently though?

[samypr100]

Added in 65a5c35 and 783a419. I didn't see reqwest allowing us to look at config.timeout, so I ended up exposing our timeout to the RegistryClient struct instead.

[zanieb]

Thanks for contributing!

I'd really like to explore addressing this at its root too, it seems like our timeout is not correctly configured.

Regarding testing, maybe we'd spin up a temporary webserver that just doesn't respond? That feels beyond the scope of this change though. A manual test should suffice for now.

[charliermarsh]

Thanks!