Move environment variable parsing to `EnvironmentOptions`

[zanieb]

In #14662 I added a new EnvironmentOptions abstraction which allows us to express semantics that Clap cannot and perform up-front parsing of non-CLI environment variables, e.g., #14544 and #14369.

We should move other extraneous environment variables to be parsed there and provided through our usual settings structs.

These changes should be relatively easy. We should probably do it one variable at a time.

• UV_HTTP_RETRIES
• UV_COMPILE_BYTECODE_TIMEOUT
• UV_HTTP_TIMEOUT
• UV_REQUEST_TIMEOUT
• HTTP_TIMEOUT
• UV_RUN_RECURSION_DEPTH
• UV_RUN_MAX_RECURSION_DEPTH
• UV_CONCURRENT_DOWNLOADS
• UV_CONCURRENT_BUILDS
• UV_CONCURRENT_INSTALLS
• UV_PYTHON_INSTALL_MIRROR
• UV_PYPY_INSTALL_MIRROR
• UV_PYTHON_DOWNLOADS_JSON_URL
• UV_NO_GITHUB_FAST_PATH
• UV_GITHUB_FAST_PATH_URL
• UV_GIT_LFS
• UV_CUDA_DRIVER_VERSION
• UV_AMD_GPU_ARCHITECTURE
• UV_STACK_SIZE
• UV_LOG_CONTEXT
• TRACING_DURATIONS_FILE
• UV_LOCK_TIMEOUT ( Add a 5 min default timeout for deadlocks  #16342 (comment))

[zanieb]

For people that want to help out, it'd be good to search for other variables I should add to the todo list.

[zanieb]

I pulled a bunch with AI, feel free to say that we shouldn't apply it for a given variable if it doesn't make sense.

[Zaloog]

Hi @zanieb may I take this one?

Just started learning rust (motivated by astrals work in the python field), but this looks like a good issue to start getting more into it.
I might need some guidance on the way though :)

Since the boolean parsing is already defined, adding the boolean env vars to EnvironmentOptions should be relative straightforward or?
What do you mean exactly by one variable at a time?

Best regards

[zanieb]

Hey @Zaloog, yeah these should be fairly straight-forward. By "one at a time" I mean start with just (for example) UV_HTTP_RETRIES and make sure we're aligned on the pattern instead of moving all of these variables at once.

[Zaloog]

like that @zanieb?

[zanieb]

You'll then need to propagate it to where it's used.

[Zaloog]

the UV_NO_GITHUB_FAST_PATH env var is used in the uv-git crate here,

Id think that I have to add uv-settings as workspace dependency to uv-git to propagate the EnvironmentsOptions,
I tried to do that, it fails though due to a circular import.

Or is there a different approach im not aware of?

[zanieb]

Can't you propagate the setting without passing the entire settings struct?

[zanieb]

You may have picked a hard setting to start with, because the GitResolver doesn't currently store state so you'll either need to make it hold settings or propagate the setting via invocations to the fast path by exposing it on the BuildContext. I'm not sure which is cleaner without digging deeper! We do stash some settings on GitSource so maybe that's the place to do so?

[Zaloog]

I started with the UV_LOG_CONTEXT, the other two booleans might be more effort like you mentioned above.

Is the approach on propagating it correct in that case?

For the int-like environment variables, id take a look on how the parsing is done on some current implementation and then
implement a function similar to parse_boolish_environment_variable but for integers.

For the string value ones, I think we could break those down further e.g. in environment variables which expect a pathlike string.

But id focus on the int ones first if thats ok