Avatar for the astral-sh user
astral-sh
uv
BlogDocsChangelog

Performance History

Latest Results

Update snapshots of other `uv init` uses too.
konsti/package-by-default-stabilize
7 hours ago
Package by default
konsti/package-by-default
7 hours ago
trampolines: Don't set PYTHONHOME; set __PYVENV_LAUNCHER__ only in venvs PYTHONHOME isn't automatically cleaned up, so setting it causes it to leak to child processes of Python, e.g., other, unrelated (perhaps not even uv-controlled) Python builds, which breaks them. Never setting it fixes #19080. However, on the implementation of getpath on Python 3.10 and below, leaving PYTHONHOME unset and pointing __PYVENV_LAUNCHER__ at something that isn't a venv or a directly-usable Python installation (for example, pointing it to .local\bin\python3.10.exe) causes Python startup to fail. So we only should be setting it inside a venv, i.e., if the trampoline itself (not the target executable) is in a venv. Presumably this failure on 3.10 is why we started setting PYTHONHOME in the first place. See brief discussion in https://github.com/astral-sh/uv/pull/13531/files#diff-969979506be03e89476feade2edebb4689a9c261f325988d3c7efc5e51de26d1 The putative benefit of setting __PYVENV_LAUNCHER__ is to force Python's idea of its own path to be the non-resolved junction path (e.g. uv\python\cpython-3.10-..., not uv\python\cpython-3.10.0-...), to help transparent version upgrades. If we don't manually set it to the non-resolved path, there's a risk that Windows will resolve it. However, empirically on Server 2022, Windows does not resolve it. (Also, even if it does get canonicalized, that has a very limited impact on transparent version upgrades, as venvs still list the junction path in pyvenv.cfg and inside the trampoline. The only impact here is that sys.path etc. might end up listing patch-version-specific paths, which would impact some cases where code serializes the full path to something in the stdlib or to sys._base_executable and calls it later. Also, Linux builds of python-build-standalone have been fully canonicalizing this path since December when we patched getpath to look at /proc/self/exe. That new behavior is arguably a bug but this hasn't seemed to cause any practical issues, so it doesn't seem like a real problem to risk Windows perhaps doing the same thing.) Unrelatedly, while we're rebuilding trampolines anyway, link with /DEBUG:NONE to avoid storing the debug directory in the PE file, which should slightly (but not entirely) reduce the amount of binary churn.
geofft/no-pythonhome-in-trampoline
7 hours ago
filter `[exclude-newer-package]` lockfile entries to resolved packages
Aditya-PS-05:fix/exclude-newer-package-lockfile-leak
8 hours ago
Update snapshots of other `uv init` uses too.
konsti/package-by-default-stabilize
8 hours ago
Code style
konsti/package-by-default
8 hours ago
Update bare docs
konsti/package-by-default
9 hours ago

Latest Branches

CodSpeed Performance Gauge
+1%
Package by default: Stabilize preview feature#19197
10 hours ago
4bef47b
konsti/package-by-default-stabilize
CodSpeed Performance Gauge
-1%
3 months ago
e44f8c1
konsti/package-by-default
CodSpeed Performance Gauge
-2%
9 hours ago
9df05a1
geofft/no-pythonhome-in-trampoline
Ā© 2026 CodSpeed Technology
Home Terms Privacy Docs