404 commits

Author	SHA1	Message	Date
Charlie Marsh	ac84f5aedc	Move preview features into a dedicated crate (#15482) ... ## Summary This is causing some cyclic dependencies issues for me, because these can be used in virtually _any_ crate (like `uv-install-wheel`), which then means that all of `uv-configuration` becomes a dependency, etc. I think this should be a leaf crate so that we can safely depend on it anywhere.	2025-08-24 09:55:30 -04:00
konsti	25bedeadea	Stop leaking strings in Python downloads (#15418) ... We should not unnecessarily leak memory. Instead, we follow the general patterns and use `Cow` for strings that can be from either a static or a dynamic source.	2025-08-21 17:54:39 +02:00
github-actions[bot]	f1a023d384	Update Pyodide to 0.28.2 (#15385) ... Automated update for Python releases. Co-authored-by: zanieb <2586601+zanieb@users.noreply.github.com>	2025-08-21 01:04:15 +00:00
github-actions[bot]	724e4c7e5e	Sync latest Python releases (#15363) ... Automated update for Python releases. --------- Co-authored-by: zanieb <2586601+zanieb@users.noreply.github.com> Co-authored-by: Zanie Blue <contact@zanie.dev>	2025-08-18 21:49:00 +00:00
Zanie Blue	00e888098f	Skip interpreters that are not found on query (#15315) ... Closes https://github.com/astral-sh/uv/issues/12155 We already throw this error earlier if we cannot find the interpreter c318e8860e/crates/uv-python/src/interpreter.rs (L1039) Why the pyenv-win shim _exists_ but fails to run with a not found error is beyond me. I think I'll take the incremental improvement here by just ignoring it. We can try to support their shims later? #15317 confirms the fix.	2025-08-18 10:42:48 -05:00
github-actions[bot]	42beb20b90	Add Python 3.14.0rc2 (#15285) ... Automated update for Python releases. Co-authored-by: zanieb <2586601+zanieb@users.noreply.github.com>	2025-08-14 13:18:36 -05:00
github-actions[bot]	c4e5984258	Sync latest Python releases (#15266) ... Automated update for Python releases. Co-authored-by: zanieb <2586601+zanieb@users.noreply.github.com>	2025-08-14 04:28:47 +00:00
Zanie Blue	2c54d3929c	Allow selection of pyodide interpreters with "pyodide" (#15256)	2025-08-13 19:08:55 +00:00
Ahmed Ilyas	88a7b2d864	Fix clippy warnings in downloads.rs (#15255) ... ## Summary Fixes clippy warnings on main. ## Test Plan `cargo clippy`	2025-08-13 12:21:03 -05:00
Hood Chatham	c8d0bfba5c	Add support for installing pyodide Pythons (#14518) ... - [x] Add tests --------- Co-authored-by: Zanie Blue <contact@zanie.dev>	2025-08-13 11:03:25 -05:00
Zanie Blue	b38edb9b7d	Allow Python requests with missing segments (#14399) ... This allows `PythonDownloadRequest` which is used for parsing general install key requests to have missing segments, which unblocks requests like `windows-aarch64` or `cpython-linux` (whereas before those would require `any-any-windows-aarch64` and `cpython-any-linux` respectively). We still require strict ordering of segments. Previously, we only allowed missing segments at the end of the key. This uses a state machine for parsing, which is quite a bit more complicated. I'm a little hesitant about the possibility that this regresses error messages and the complexity of the implementation, but `uv run -p aarch64` seems valuable following #13724. The alternative to this would probably be to make these explicit in various places? e.g., expose `--python-arch`, `--python-libc`, and `--python-os`? Or make `--python-platform` (which already exists) accept a subset of the keys? There is a possibility of regressions here, e.g., if something matches this parser it will not fallback to the `PythonRequest::ExecutableName` case and we've made this parser more permissive, but I think that should be quite rare?	2025-08-13 11:03:09 -05:00
Zanie Blue	78c8c711fa	Refactor os, arch, and libc information into a shared Platform type (#15027) ... Addresses this outstanding item from a previous review https://github.com/astral-sh/uv/pull/13724#discussion_r2114867288 I'm interested in this now for consolidating some logic in #12731	2025-08-13 09:02:55 -05:00
github-actions[bot]	ed499d7453	Sync latest Python releases (#15186) ... Automated update for Python releases. Co-authored-by: zanieb <2586601+zanieb@users.noreply.github.com>	2025-08-09 00:43:10 +00:00
github-actions[bot]	d1beb7f640	Sync latest Python releases (#15171) ... Automated update for Python releases. This picks up dynamically-linked tkinter/libtcl/libtk, which fixes #6893 and a host of similar issues. Co-authored-by: Geoffrey Thomas <geofft@ldpreload.com>	2025-08-08 19:03:25 +00:00
Zanie Blue	bdb4b061db	Include all site packages directories in ephemeral environment overlays (#15121) ... Related to https://github.com/astral-sh/uv/issues/15113 The case in the linked issue is that we perhaps should not be allowing `uv run --with` with system interpreters at all. I think we can consider that, but the issue highlighted that `uv run --with` for a system interpreter is broken if the base interpreter has custom site packages. This generalizes beyond system interpreters so we should probably fix our overlays.	2025-08-08 13:49:21 -05:00
samypr100	57df0146e2	Update Rust toolchain to 1.89 (#15157) ... ## Summary Bumps Rust toolchain to 1.89, but not the MSRV. Lifetime changes is related to a new lint rule explained in https://blog.rust-lang.org/2025/08/07/Rust-1.89.0/#mismatched-lifetime-syntaxes-lint ## Test Plan Existing Tests	2025-08-08 13:01:52 +00:00
Michael Šimáček	e5eec05783	Ignore GraalPy devtag (#15013) ... Allows [development builds of GraalPy](https://github.com/graalvm/graal-languages-ea-builds) to work with uv. CC @timfel	2025-08-07 15:53:37 -05:00
github-actions[bot]	038bf56366	Sync latest Python releases (#15135) ... Automated update for Python releases. Co-authored-by: zanieb <2586601+zanieb@users.noreply.github.com>	2025-08-07 13:59:02 +00:00
adamnemecek	3f83390e34	Make the use of Self consistent. (#15074) ... ## Summary Make the use of `Self` consistent. Mostly done by running `cargo clippy --fix -- -A clippy::all -W clippy::use_self`. ## Test Plan <!-- How was it tested? --> No need.	2025-08-05 20:17:12 +01:00
Zanie Blue	8db61abb50	Prefer system Python installations over managed ones when --system is used (#15061) ... This fixes a regression from 0.8.0 from https://github.com/astral-sh/uv/pull/7934 and follows https://github.com/astral-sh/uv/pull/15059 The regression is from [this change](https://github.com/astral-sh/uv/pull/7934/files#diff-c7a660ac39628d5e12f388b0cacc7360affa3d7bb21191184d7ee78489675e83), which was made because we'd otherwise (with the other changes in that pull request) _filter out_ managed Python interpreters found in virtual environments. When `--system` is used we'll convert the default Python preference of `managed` to `system` which avoids things like `uv pip install --system` targeting a managed Python installation. The basic test is ``` uv python install uv pip install --system anyio ``` Prior to this change, we'd read a managed interpreter from our managed installation directory and target that. After this change, without #15059, we'd read a managed interpreter from the PATH and target that. Both of those experiences are bad, because the managed interpreters are marked as externally managed. After this change, with #15059, we properly target the system interpreter. Since we use `system` instead of `only-system`, if there is not a system interpreter we'll still retain our existing behavior and use a managed interpreter. This should limit breakage from the change. Given the source of the regression, we could probably use `only-system` here. I don't feel strongly. I think the main benefit of doing so would be that we'd omit the check for managed installations in error messages when an interpreter cannot be found? We can't really add test coverage here because the test suite always has externally managed interpreters :)	2025-08-04 19:53:59 -05:00
Zanie Blue	64e91a7e87	Fix handling of python-preference = system when managed interpreters are on the PATH (#15059) ... This is the first part of fixing a 0.8.0 regression from https://github.com/astral-sh/uv/pull/7934 There, we added handling for skipping managed interpreters on the PATH when `only-system` is used, but did not update the logic to prefer system interpreters over managed ones when `system` is used. Here, we fix that by skipping managed interpreters when `system` is used unless _only_ managed interpreters are available. While this logic is applied during in a general discovery method, it's only relevant for the PATH (and the Windows registry) because we already change the _order_ that we inspect installations in when `system` is used, so the managed installation directory is inspected last. This behavior did not regress in 0.8, it's always been this way, however, I need this change in order to fix a different bug.	2025-08-04 16:02:42 +00:00
Zanie Blue	00efde06b6	Split platform detection code into a dedicated uv-platform crate (#14918) ... In service of some subsequent work...	2025-07-28 14:12:04 -05:00
Zanie Blue	a701d3c447	Use workspace dependencies for crate dev-dependencies (#14903)	2025-07-25 13:57:49 -05:00
Zanie Blue	bfb4bc2aeb	Split preview mode into separate feature flags (#14823) ... I think this would give us better hygiene than a global flag. It makes it easier for users to opt-in to overlapping features, such as Python upgrades and Python bin installations and to disable warnings for preview mode without opting in to a bunch of other features. In general, I want to reduce the burden for putting something under preview. The `--preview` and `--no-preview` flags are retained as global overrides. A new `--preview-features` option is added which accepts comma separated features or can be passed multiple times, e.g., `--preview-features add-bounds,pylock`. There's a `UV_PREVIEW_FEATURES` environment variable for that option (I'm not sure if we should overload `UV_PREVIEW`, but could be convinced).	2025-07-25 11:01:57 -05:00
konsti	f7ac6875c3	Improve concurrency safety of Python downloads into cache (#14846)	2025-07-23 11:52:39 -05:00
github-actions[bot]	310a9d3426	Sync latest Python releases (#14847) ... Automated update for Python releases. Co-authored-by: zanieb <2586601+zanieb@users.noreply.github.com>	2025-07-23 11:01:09 -05:00
Charlie Marsh	d052427c37	Accept &Path when creating executable links (#14791) ... ## Summary I don't see a great reason for this to take an owned value. It only needs an owned value for error cases.	2025-07-21 11:53:28 -04:00
Jo	9983273289	Use sha256 checksum from GitHub API for GraalPy releases (#14779) ... ## Summary Follow #14078, use GitHub generated sha256 for GraalPy releases too. ## Test Plan ```console uv run ./crates/uv-python/fetch-download-metadata.py ```	2025-07-21 08:35:45 -04:00
Jo	98d6ab6632	Improve CPythonFinder._parse_download_url a bit (#14780) ... ## Summary Rename `_parse_download_url` to `_parse_download_asset` and move the `asset['digest']` logic into it. ## Test Plan ```console uv run ./crates/uv-python/fetch-download-metadata.py ```	2025-07-21 12:22:45 +02:00
konsti	574aa1ef11	Better error reporting for removing Python versions from the Windows registry (#14722) ... See 4625800484 We didn't actual use a format string, showing the template instead. We don't show the causes in the error report, so we format it into one error.	2025-07-18 13:26:47 +00:00
konsti	d1f4f8a358	More resilient registry removal (#14717) ... With the previous order of operations, there could be warnings from race conditions between two process A and B removing and installing Python versions. * A removes the files for CPython3.9.18 * B sees the key CPython3.9.18 * B sees that CPython3.9.18 has no files * A removes the key for CPython3.9.18 * B try to removes the key for CPython3.9.18, gets and error that it's already gone, issues a warning We make the more resilient in two ways: * We remove the registry key first, avoiding dangling registry keys in the removal process * We ignore not found errors in registry removal operations: If we try to remove something that's already gone, that's fine. Fixes #14714 (hopefully)	2025-07-18 12:47:56 +00:00
konsti	327c2bcd8a	Use SHA256 from GitHub API for Python downloads (#14708) ... We recently ran over the file limit and had to drop hash file from the releases page in favor of bulk SHA256SUMS files (https://github.com/astral-sh/python-build-standalone/pull/691). Conveniently, GitHub has recently started to add a SHA256 digest to the API. GitHub did not backfill the hashes for the old releases, so use the API hashes for newer assets, and eventually only download SHA256SUMS for older releases.	2025-07-18 14:03:55 +02:00
Zanie Blue	b98ac8c224	Validate that discovered interpreters meet the Python preference (#7934) ... Closes https://github.com/astral-sh/uv/issues/5144 e.g. ``` ❯ cargo run -q -- sync --python-preference only-system Using CPython 3.12.6 interpreter at: /opt/homebrew/opt/python@3.12/bin/python3.12 Removed virtual environment at: .venv Creating virtual environment at: .venv Resolved 9 packages in 14ms Installed 8 packages in 9ms + anyio==4.6.0 + certifi==2024.8.30 + h11==0.14.0 + httpcore==1.0.5 + httpx==0.27.2 + idna==3.10 + ruff==0.6.7 + sniffio==1.3.1 ❯ cargo run -q -- sync --python-preference only-managed Using CPython 3.12.1 Removed virtual environment at: .venv Creating virtual environment at: .venv Resolved 9 packages in 14ms Installed 8 packages in 11ms + anyio==4.6.0 + certifi==2024.8.30 + h11==0.14.0 + httpcore==1.0.5 + httpx==0.27.2 + idna==3.10 + ruff==0.6.7 + sniffio==1.3.1 ```	2025-07-17 17:20:21 -05:00
Charlie Marsh	6df7dab2df	Use an ephemeral environment for uv run --with invocations (#14447) ... This PR creates separation between the `--with` environment and the environment we actually run in, which in turn solves issues like https://github.com/astral-sh/uv/issues/12889 whereby two invocations share the same `--with` environment, causing them to collide by way of sharing an overlay. Closes https://github.com/astral-sh/uv/issues/7643.	2025-07-17 17:20:21 -05:00
Zanie Blue	c8925e2541	Require --global for removal of the global Python pin (#14169) ... While reviewing https://github.com/astral-sh/uv/pull/14107, @oconnor663 pointed out a bug where we allow `uv python pin --rm` to delete the global pin without the `--global` flag. I think that shouldn't be allowed? I'm not 100% certain though.	2025-07-17 17:20:21 -05:00
github-actions[bot]	eaff96e5dc	Sync latest Python releases (#14643) ... Automated update for Python releases. Co-authored-by: zanieb <2586601+zanieb@users.noreply.github.com>	2025-07-16 09:06:06 -05:00
Nathan Cain	e547527587	Add UV_LIBC to allow libc selection in multi-libc environment (#14646) ... Closes #14262 ## Description Adds `UV_LIBC` environment variable and implements check within `Libc::from_env` as recommended here: https://github.com/astral-sh/uv/issues/14262#issuecomment-3014600313 Gave this a few passes to make sure I follow dev practices within uv as best I am able. Feel free to call out anything that could be improved. ## Test Plan Planned to simply run existing test suite. Open to adding more tests once implementation is validated due to my limited Rust experience.	2025-07-16 08:52:17 -05:00
Zanie Blue	863e73a841	Skip Windows Python interpreters that return a broken MSIX package code (#14636) ... Currently we treat all spawn failures as fatal, because they indicate a broken interpreter. In this case, I think we should just skip these broken interpreters — though I don't know the root cause of why it's broken yet. Closes https://github.com/astral-sh/uv/issues/14637 See 1394758502	2025-07-15 16:47:35 -05:00
Zanie Blue	bb1e9a247c	Update preview installation of Python executables to be non-fatal (#14612) ... Previously, if installation of executables into the bin directory failed we'd with a non-zero code. However, if we make this behavior the default we don't want it to be fatal. There's a `--bin` opt-in to _require_ successful executable installation and a `--no-bin` opt-out to silence the warning / opt-out of installation entirely. Part of https://github.com/astral-sh/uv/issues/14296 — we need this before we can stabilize the behavior. In #14614 we do the same for writing entries to the Windows registry.	2025-07-15 17:12:36 +00:00
github-actions[bot]	4175e3eb4d	Sync latest Python releases (#14581) ... Automated update for Python releases. Co-authored-by: zanieb <2586601+zanieb@users.noreply.github.com>	2025-07-13 08:20:51 -05:00
Geoffrey Thomas	7ea030a1a8	Bump Python releases to pick up python-build-standalone 20250712 (#14578) ... This is primarily a regression fix for missing SQLite extensions (astral-sh/python-build-standalone#694).	2025-07-12 12:46:40 -04:00
Zanie Blue	02345a5a7d	Add hint when Python downloads are disabled (#14522) ... Follow-up to https://github.com/astral-sh/uv/pull/14509 to provide the _reason_ downloads are disabled and surface it as a hint rather than a debug log. e.g., ``` ❯ cargo run -q -- run --no-managed-python -p 3.13.4 python error: No interpreter found for Python 3.13.4 in virtual environments or search path hint: A managed Python download is available for Python 3.13.4, but the Python preference is set to 'only system' ```	2025-07-10 12:06:24 -05:00
github-actions[bot]	92716606e5	Sync latest Python releases (#14531) ... Automated update for Python releases. Co-authored-by: zanieb <2586601+zanieb@users.noreply.github.com>	2025-07-10 00:40:58 +00:00
Kevin Nakamura	1958aa26bd	Add debug message when skipping Python downloads (#14509) ... # Description Several users, myself included, had some issues with Anki (recently migrated to uv). https://forums.ankiweb.net/t/bug-anki-25-07-fails-to-launch-on-linux/63475 zanieb came in and gave us pointers, including looking at our uv logs. https://github.com/ankitects/anki/pull/4074#issuecomment-3046992777 log: https://github.com/Grinkers/uv/pull/1#issuecomment-3047538135 The actual issue was that I had a system config in /etc/uv/uv.toml but uv wasn't giving useful feedback for its combining/unification. A higher level issue is that there's nice logs, however logging is initialized after! We want to log files read, but need to read the files to know what log level to use. 7e48292fac/crates/uv-settings/src/lib.rs (L68) 7e48292fac/crates/uv/src/lib.rs (L354) zanieb mentioned there's https://github.com/astral-sh/uv/issues/13123, so consider this a +1 to that. ## Result The end of the output will be: ``` DEBUG Downloads disabled. Skipping... DEBUG Released lock at `/tmp/uv-823c7b0e73da3e08.lock` error: No interpreter found for Python 3.13.5 in managed installations ``` Sorry for the minuscule sized PR. Feel free to close if there's a bigger logging pass. --------- Co-authored-by: Zanie Blue <contact@zanie.dev>	2025-07-09 15:56:48 +00:00
github-actions[bot]	afcbcc7498	Sync latest Python releases (#14514) ... Automated update for Python releases. Co-authored-by: zanieb <2586601+zanieb@users.noreply.github.com>	2025-07-08 21:12:22 -05:00
github-actions[bot]	e31f556205	Sync latest Python releases (#14452) ... Automated update for Python releases. Co-authored-by: zanieb <2586601+zanieb@users.noreply.github.com>	2025-07-08 00:53:38 +00:00
konsti	06af93fce7	Fix optional cfg gates (#14448) ... Running `cargo clippy` in individual crates could raise warnings due to unused imports as `Cow` is only used with `#[cfg(feature = "schemars")]`	2025-07-03 15:29:03 -05:00
github-actions[bot]	3bb8ac610c	Sync latest Python releases (#14426) ... Automated update for Python releases. Co-authored-by: zanieb <2586601+zanieb@users.noreply.github.com>	2025-07-02 14:51:17 -05:00
Jack O'Connor	85358fe9c6	Keep track of retries in ManagedPythonDownload::fetch_with_retry ... If/when we see https://github.com/astral-sh/uv/issues/14171 again, this should clarify whether our retry logic was skipped (i.e. a transient error wasn't correctly identified as transient), or whether we exhausted our retries. Previously, if you ran a local example fileserver as in https://github.com/astral-sh/uv/issues/14171#issuecomment-3014580701 and then you tried to install Python from it, you'd get: ``` $ export UV_TEST_NO_CLI_PROGRESS=1 $ uv python install 3.8.20 --mirror http://localhost:8000 2>&1 | cat error: Failed to install cpython-3.8.20-linux-x86_64-gnu Caused by: Failed to extract archive: cpython-3.8.20-20241002-x86_64-unknown-linux-gnu-install_only_stripped.tar.gz Caused by: failed to unpack `/home/jacko/.local/share/uv/python/.temp/.tmpS4sHHZ/python/lib/libpython3.8.so.1.0` Caused by: failed to unpack `python/lib/libpython3.8.so.1.0` into `/home/jacko/.local/share/uv/python/.temp/.tmpS4sHHZ/python/lib/libpython3.8.so.1.0` Caused by: error decoding response body Caused by: request or response body error Caused by: error reading a body from connection Caused by: Connection reset by peer (os error 104) ``` With this change you get: ``` error: Failed to install cpython-3.8.20-linux-x86_64-gnu Caused by: Request failed after 3 retries Caused by: Failed to extract archive: cpython-3.8.20-20241002-x86_64-unknown-linux-gnu-install_only_stripped.tar.gz Caused by: failed to unpack `/home/jacko/.local/share/uv/python/.temp/.tmp4Ia24w/python/lib/libpython3.8.so.1.0` Caused by: failed to unpack `python/lib/libpython3.8.so.1.0` into `/home/jacko/.local/share/uv/python/.temp/.tmp4Ia24w/python/lib/libpython3.8.so.1.0` Caused by: error decoding response body Caused by: request or response body error Caused by: error reading a body from connection Caused by: Connection reset by peer (os error 104) ``` At the same time, I'm updating the way we handle the retry count to avoid nested retry loops exceeding the intended number of attempts, as I mentioned at https://github.com/astral-sh/uv/issues/14069#issuecomment-3020634281. It's not clear to me whether we actually want this part of the change, and I need feedback here.	2025-07-01 09:52:19 -07:00
github-actions[bot]	a3db9a9ae4	Sync latest Python releases (#14381) ... Automated update for Python releases. Co-authored-by: zanieb <2586601+zanieb@users.noreply.github.com>	2025-07-01 03:44:18 +00:00