feat: add linehaul info to uv-client#2493
Conversation
We now have this information for the python interpreter itself, i added it.
Great performance work! On my machine (ubuntu) we're at 0.000s and even relative to the 2ms warm cache black resolve the linehaul instantiation is fast. Warm cache resolve black |
| use serde::Deserialize; | ||
|
|
||
| /// Get the macOS version from the SystemVersion.plist file. | ||
| pub(crate) fn get_mac_os_version() -> Result<String, PlatformError> { |
There was a problem hiding this comment.
Do we need this? I thought we got it from the interpreter now.
There was a problem hiding this comment.
Note, it's not quite just major.minor, it should include the product version from the plist as-is based on my testing with pip.
There was a problem hiding this comment.
Happy to hand this off to a mac user who can test this on an actual mac
See #2493 (review). --------- Co-authored-by: Zanie Blue <contact@zanie.dev>
|
I tried to query the big-data table for |
|
Yes, a parser can now be added since the data is being sent as of 0.1.22 ❤️ |
Summary
Closes #1958
This adds linehaul metadata to uv's user-agent when pep 508 markers are provided to the RegistryClientBuilder. Thanks to #2381, we were able to leverage most information from markers and avoid inconsistency.
Linehaul is meant to be accompanying metadata pip sends in it's user agent when talking to registries. You can see this output by running something like
python -c 'from pip._internal.network.session import user_agent; print(user_agent())'.In PyPI, this metadata processed by the linehaul-cloud-function. More info about linehaul can be found in #1958.
Below are some examples from pip:
pip/24.0 {"ci":true,"cpu":"x86_64","distro":{"id":"jammy","libc":{"lib":"glibc","version":"2.35"},"name":"Ubuntu","version":"22.04"},"implementation":{"name":"CPython","version":"3.12.2"},"installer":{"name":"pip","version":"24.0"},"openssl_version":"OpenSSL 3.0.2 15 Mar 2022","python":"3.12.2","rustc_version":"1.76.0","system":{"name":"Linux","release":"6.5.0-1016-azure"}}pip/24.0 {"ci":true,"cpu":"AMD64","implementation":{"name":"CPython","version":"3.12.2"},"installer":{"name":"pip","version":"24.0"},"openssl_version":"OpenSSL 3.0.13 30 Jan 2024","python":"3.12.2","rustc_version":"1.76.0","system":{"name":"Windows","release":"2022Server"}}pip/24.0 {"ci":true,"cpu":"arm64","distro":{"name":"macOS","version":"14.2.1"},"implementation":{"name":"CPython","version":"3.12.2"},"installer":{"name":"pip","version":"24.0"},"openssl_version":"OpenSSL 3.0.13 30 Jan 2024","python":"3.12.2","rustc_version":"1.76.0","system":{"name":"Darwin","release":"23.2.0"}}Here's how uv results look like (sorry for the keys not having the same order):
uv/0.1.21 {"installer":{"name":"uv","version":"0.1.21"},"python":"3.12.2","implementation":{"name":"CPython","version":"3.12.2"},"distro":{"name":"Ubuntu","version":"22.04","id":"jammy","libc":null},"system":{"name":"Linux","release":"6.5.0-1016-azure"},"cpu":"x86_64","openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":true}uv/0.1.21 {"installer":{"name":"uv","version":"0.1.21"},"python":"3.12.2","implementation":{"name":"CPython","version":"3.12.2"},"distro":null,"system":{"name":"Windows","release":"2022Server"},"cpu":"AMD64","openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":true}uv/0.1.21 {"installer":{"name":"uv","version":"0.1.21"},"python":"3.12.2","implementation":{"name":"CPython","version":"3.12.2"},"distro":{"name":"macOS","version":"14.2.1","id":null,"libc":null},"system":{"name":"Darwin","release":"23.2.0"},"cpu":"arm64","openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":true}Distro information (such as the one pip uses
from pip._vendor import distroto retrieve instead ofplatformmodule) was not retrieved from markers. Instead, the linux release codename/name/version usessys-infocrate, adding about 50us of extra overhead on linux. The distro osx version re-used the mac_os version implementation from #2381 which adds about 20us of overhead on osx. I tried to use other crates to avoid re-introducingmac_os.rsbut most of them didn't yield satisfactory performance (40ms-60ms~) or had the wrong values needed (e.g. darwin version vs osx version).I also didn't add rustc retrieval as those seem to add substantial overhead due to querying
rustc. PyPy version detection was also not added to avoid adding extra overhead to support PyPy for linehaul. All other behavior was kept 1-1 to match what pip's linehaul implementation does (as of 24.0). This also aligns with what was discussed in #1958.Test Plan
Added new integration test to uv-client.