User Agent includes uv's version

[samypr100]

Currently when uv makes requests the User Agent is set to just uv.

It would be nice that it includes the version (e.g. uv/{version}) for improved visibility and statistics for the registry provider on the client being used.

For example, pip usually has pip/{version} {other metadata}, curl has curl/{version}, httpx has httpx/{version}, requests has python-requests/{version}, and so forth. Hence uv/{version} seems like the correct way to go.

[samypr100]

Upon looking at uv-client, I see that's where the User Agent seems to be set for all request across all packages, so there's likely a couple solutions to this depending on the approach since that's where the user agent is being set.

• Option 1: Expose a module in uv-client that allows to globally/static set the UA version (e.g. via OnceCell with getter/setter) and set the version once at the beginning in UV's main entrypoint function.

• Option 2: Create a new crate (e.g. uv-version or uv-codex) that has becomes the single source of truth for this type of data given cargo dependencies are unidirectional.

• Option 3: Change RegistryClientBuilder to take a UA version and modify all related interfaces (among all dependencies) to pass down uv's version across the codebase to RegistryClientBuilder. Not entirely sure of the complexity here (e.g. if there's only one client or multiple standalone clients across dependencies).

• Option 4: Maybe we could use cargo feature flags to hack around it, but that'd seems burdensome to maintain.

Option 1 seems the most straightforward, but if we are thinking of adding more data to be shared by other modules maybe Option 2 is best. If the type of data in the User Agent (or other request headers) end up being more dynamic over time, then Option 3 might be needed instead.

Thoughts here?

Maybe related note: pip itself seems to also include other metadata in JSON form in the User Agent header. Seems like the data described in https://github.com/astral-sh/uv/issues/1958?

[charliermarsh]

I think if we just wanted to include the version, something like (1) would be fine. Although, it's possible we can just use env!("CARGO_PKG_VERSION") to inline the version in uv-client, and not make any other code changes?

If we want to support https://github.com/astral-sh/uv/issues/1958 though, we'll need a way to set the user agent based on the Python interpreter. We have that information in-memory already, but threading it through to the client will require some work.

[samypr100]

Although, it's possible we can just use env!("CARGO_PKG_VERSION") to inline the version in uv-client, and not make any other code changes?

I was intitially thinking it would be ideal to be uv's version and not uv-client's version otherwise I think the header would be uv/0.0.1 versus uv/0.1.10 unless you're thinking of aligning the uv-* package versions the same as uv, which would also be a valid option here.

[charliermarsh]

Oh yes, sorry, it should definitely be the uv version. (I was confused because we use env!("CARGO_PKG_VERSION") for the virtualenv, but that code is actually in the uv crate, not a layer below.)