Fixes#12914.
When `PythonDownloadRequest` does not have the `implementation` set, do
not set it to CPython when calling `fill`, otherwise only CPython
interpreters are shown when listing interpreters available for download,
with `uv python list`.
## Summary
This PR simplifies the version formatting by replacing `.white()` with
`.cyan()` styling for consistency.
Resolves#12940
## Test Plan
I manually recreated the code and tested it with this patch:
```diff
diff --git i/crates/uv/src/lib.rs w/crates/uv/src/lib.rs
index b9c01b002..cf051351f 100644
--- i/crates/uv/src/lib.rs
+++ w/crates/uv/src/lib.rs
@@ -1019,6 +1019,20 @@ async fn run(mut cli: Cli) -> Result<ExitStatus> {
}) => commands::self_update(target_version, token, printer).await,
#[cfg(not(feature = "self-update"))]
Commands::Self_(_) => {
+ eprintln!("{}: {}", "error".cyan().bold(), "fake error message");
+
+ let version_information = format!(
+ "from {} to {}",
+ "v0.1.1".bold().cyan(),
+ "v0.1.2".bold().cyan(),
+ );
+ eprintln!(
+ "{}{} Upgraded uv {}! {}",
+ "success".green().bold(),
+ ":".bold(),
+ version_information,
+ format!("https://github.com/astral-sh/uv/releases/tag/{}", "v0.1.2").cyan()
+ );
anyhow::bail!(
"uv was installed through an external package manager, and self-update \
is not available. Please use your package manager to update uv."
```
In a light terminal, this is what it looks like:
<img width="750" alt="image"
src="https://github.com/user-attachments/assets/dc0d283c-e845-41fb-9821-80b0a3f1c4fe"
/>
Closes#12929
## Summary
Untag the `config-settings` value to support JSON schema according to
the
[docs](https://docs.astral.sh/uv/reference/settings/#config-settings).
```toml
[tool.uv]
config-settings = { editable_mode = "compat" }
```
<!-- What's the purpose of the change? What does it do, and why? -->
## Test Plan
Verified using the "Even Better TOML" extension with paths to old and
new `uv.schema.json`.
## Notes
I could not reproduce the issue with either the `taplo` (on which Even
Better Toml is built, afaik) and `check-jsonschema` CLI tools; with both
old and new versions of the `uv.schema.json` validated the
`pyproject.toml`.
Maybe for these there is some additional regularization going on and
that's also how a breaking case ended up in the docs?
I'm unsure on how to test for this.
After about an hour, the Even better TOML VSCode extension was the only
way to reproduce failing validation.
Let me know if I can do something else.
<!-- How was it tested? -->
Currently, `uv init` works without a `git` executable, and with a
working `git` executable, but not with a broken `git`, be it from GitHub
Action's Windows CI or from the shim we insert.
`uv init` calls git twice: Once `git rev-parse` to check whether a git
repo already exists, and then `git init` (if there is no git repository
yet and no `--vcs none`).
By separately handling the cases where git failed during `git rev-parse`
doesn't work vs. where the is no repository when checking for an
existing repo work tree, we can avoid calling `git init` for broken git
and erroring. We have to hardcode the expected git command outputs to be
able to check.
This is a rebased and updated version of #11925 based on my review (I
didn't have permission to push to their branch).
For posterity I've preserved their commits but my final commit
essentially rewrites the whole thing anyway.
Fixes#11637
---------
Co-authored-by: Chris Lieb <clieb@bitsighttech.com>
"Only show Python downloads, exclude installed distributions." might be
misunderstood as excluding installed distributions from `uv python list
--only-downloads`, implying that versions already installed won’t be
shown.
See #12769 for the motivation. We set the 4MB not only for the main
thread, but also for all tokio and rayon threads to fix a stack overflow
while unpacking wheels in production on Windows.
There are two variables for setting the stack size: A new
`UV_STACK_SIZE` that takes precedent, and the existing `RUST_MIN_STACK`.
When setting the stack size, `UV_STACK_SIZE` should be preferred, since
`RUST_MIN_STACK` affects all Rust applications, including build backends
we call (e.g., maturin). The minimum stack size is set to 1MB, the
lowest stack size we observed on a platform (Windows main thread).
Fixes#12769
## Test Plan
Tested manually with the example from #12769
## Summary
Closes#12855
This PR also fixed an issue, where `python_request` was matched against
`PythonVersion::Default`. Previously, if `python_request` was `3.13t`,
it would match the last branch, triggering a download of the Python
version if it wasn't already installed.
6b7f60c1ea/crates/uv/src/commands/project/init.rs (L421-L448)
```console
❯ uv init -v --managed-python --python 3.13t foo
DEBUG uv 0.6.14 (a4cec56dc 2025-04-09)
DEBUG Searching for Python 3.13t in managed installations
DEBUG Searching for managed installations at `/Users/Jo/.local/share/uv/python`
DEBUG Found managed installation `cpython-3.13.1-macos-aarch64-none`
DEBUG Found `cpython-3.13.1-macos-aarch64-none` at `/Users/Jo/.local/share/uv/python/cpython-3.13.1-macos-aarch64-none/bin/python3.13` (managed installations)
DEBUG Skipping interpreter at `/Users/Jo/.local/share/uv/python/cpython-3.13.1-macos-aarch64-none/bin/python3.13` from managed installations: does not satisfy request `3.13t`
DEBUG Skipping incompatible managed installation `cpython-3.12.8-macos-aarch64-none`
DEBUG Skipping incompatible managed installation `pypy-3.11.11-macos-aarch64-none`
DEBUG Requested Python not found, checking for available download...
DEBUG Acquired lock for `/Users/Jo/.local/share/uv/python`
DEBUG Using request timeout of 30s
INFO Fetching requested Python...
Downloading cpython-3.13.3+freethreaded-macos-aarch64-none (49.9MiB)
DEBUG Downloading 20250409/cpython-3.13.3%2B20250409-aarch64-apple-darwin-freethreaded%2Bpgo%2Blto-full.tar.zst to temporary location: /Users/Jo/.local/share/uv/python/.temp/.tmpfoOLkE
DEBUG Extracting cpython-3.13.3%2B20250409-aarch64-apple-darwin-freethreaded%2Bpgo%2Blto-full.tar.zst
Downloaded cpython-3.13.3+freethreaded-macos-aarch64-none
DEBUG Moving /Users/Jo/.local/share/uv/python/.temp/.tmpfoOLkE/python/install to /Users/Jo/.local/share/uv/python/cpython-3.13.3+freethreaded-macos-aarch64-none
DEBUG Released lock at `/Users/Jo/.local/share/uv/python/.lock`
DEBUG Writing Python versions to `/private/tmp/foo/.python-version`
Initialized project `foo` at `/private/tmp/foo`
❯ cat foo/.python-version
3.13
```
After this PR, uv will not try to download it:
```console
❯ uv python uninstall 3.13t
❯ cargo run -- init -v --managed-python --python 3.13t bar
DEBUG uv 0.6.14+15 (6b7f60c1e 2025-04-12)
DEBUG Writing Python versions to `/private/tmp/bar/.python-version`
Initialized project `bar` at `/private/tmp/bar`
❯ cat bar/.python_version
3.13t
```
It was possible that a virtual environment became out of sync with the
interpreter it pointed to (for example, if a symlink was changed to an
updated Python version). In such a case, `pyvenv.cfg` and
`activate_this.py` would no longer be correct. This PR detects when the
`version` (`venv` module) or `version_info` (uv and `virtualenv`) field
in `pyvenv.cfg` is out of sync with the interpreter. In such a case, uv
recreates the virtual environment.
Closes#12461
We have been claiming in our releases that we provide
archives/installers for uv-build, but we only upload it as a wheel to
pypi. This is because cargo-dist tries to be helpful and find all your
apps, but this scales poorly to large workspaces like ours, as stuff
like this slips in. So invert the default and make uv the only package
dist will see until we say otherwise.
See e.g. https://github.com/astral-sh/uv/releases/tag/0.6.14Fixes#12883
By default, unlike on CI, a Windows machine does not allow creating
symlinks, so we have to unix-gate tests that assume symlinks.
We can't install the transformers ecosystem test on Windows due to
missing torch, so it is also unix-gated.
Windows translates error messages, so we have to filter the "File not
found" message, since it can also be a "Datei nicht gefunden".
## Summary
Closes#12687.
<!-- What's the purpose of the change? What does it do, and why? -->
## Test Plan
<!-- How was it tested? -->
Added the corresponding integration tests for:
- `uv sync --dry-run --locked`
- [x] Preview lock changes
- [x] Errors if lockfile is out-of-date
- `uv sync --dry-run --frozen`
- [x] Preview lock changes
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
## Summary
Collapse whitespace into a single space in python_list tests, in order
to make them agnostic of padding, and therefore pass both with Python
3.12.9 and Python 3.12.10.
Fixes#12799
## Test Plan
cargo test --features python --profile=fast-build --no-default-features
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [mimalloc](https://redirect.github.com/purpleprotocol/mimalloc_rust) |
dependencies | patch | `0.1.45` -> `0.1.46` |
---
### Release Notes
<details>
<summary>purpleprotocol/mimalloc_rust (mimalloc)</summary>
###
[`v0.1.46`](https://redirect.github.com/purpleprotocol/mimalloc_rust/releases/tag/v0.1.46):
Version 0.1.46
[Compare
Source](https://redirect.github.com/purpleprotocol/mimalloc_rust/compare/v0.1.45...v0.1.46)
##### Changes
- Fixed musl builds.
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "before 4am on Monday" (UTC),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOS4yMzguMCIsInVwZGF0ZWRJblZlciI6IjM5LjIzOC4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJpbnRlcm5hbCJdfQ==-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
From PEP 440:
> The exclusive ordered comparison <V MUST NOT allow a pre-release of
the specified version unless the specified version is itself a
pre-release. Allowing pre-releases that are earlier than, but not equal
to a specific pre-release may be accomplished by using <V.rc1 or
similar.
We had an additional check that would block this even if the specifier
did have a pre-release.
This likely didn't show up earlier because `Ranges` uses different code
in the resolver.
I checked these changes against `packaging` to verify their behavior:
```python
print(SpecifierSet("<1").contains("1a1", prereleases=True)) # False
print(SpecifierSet("<1a2").contains("1a1", prereleases=True)) # True
print(SpecifierSet("<1").contains("1dev1", prereleases=True)) # False
print(SpecifierSet("<1dev2").contains("1dev1", prereleases=True)) # True
print(SpecifierSet("<1a2").contains("1dev1", prereleases=True)) # True
```
Closes#12834
## Summary
This PR errors out when an Unknown Dependency Object Specifier is used
in dependency groups.
Fixes#12638
## Test Plan
The current behaviour is as follows:
```bash
➜ example git:(12638/dependency-object-specifier) ✗ cargo run -- sync
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.21s
Running `/home/luna/Documents/uv/target/debug/uv sync`
error: Failed to generate package metadata for `example==0.1.0 @ virtual+.`
Caused by: Group `bar` contains a Dependency Object Specifier, which is not supported by uv
```
And the pyproject.toml to produce this is:
```toml
[project]
name = "example"
version = "0.1.0"
description = "Add your description here"
readme = "README.md"
requires-python = ">=3.13.2"
dependencies = []
[dependency-groups]
foo = ["pyparsing"]
bar = [{set-phasers-to = "stun"}]
```
## Summary
Closes#12806
Split `UV_INDEX` by any whitespace rather than only ASCII 32, which does
not align with the behavior of `PIP_EXTRA_INDEX_URL` and can possibly
lead to difficulties when migrating from pip to uv.
Clap unfortunately does not support passing multiple delimiters, writing
a custom parsing function involved parsing index into a Vec<Vec<Index>>
and flattening it afterwards in order to avoid breaking the --index
command line option.
There might be a prettier solution I overlooked, let me know if there is
anything I should change!
<!--
Thank you for contributing to uv! To help us out with reviewing, please
consider the following:
- Does this pull request include a summary of the change? (See below.)
- Does this pull request include a descriptive title?
- Does this pull request include references to any relevant issues?
-->
## Summary
<!-- What's the purpose of the change? What does it do, and why? -->
Adds the env arg `UV_NO_EDITABLE`.
Closes#12735
## Test Plan
<!-- How was it tested? -->
I could not find a place where to add tests, any help would be
appreciated
---------
Co-authored-by: Aria Desires <aria.desires@gmail.com>
Check that the source and module directory exist when build a source
distribution, instead of delaying the check to building the wheel. This
prevents building source distributions that can never be built into
wheels.
I removed the `set_cksum` as the value of it is replaced inside of
`append_data`.
## Summary
This should fix#12762 but I don't know how to test it.
---------
Co-authored-by: konstin <konstin@mailbox.org>
## Summary
I think the lack of enforcement here is an oversight. We _do_ already
enforce this for user-level configuration files (contrary to the issue
-- at least, in my testing and from reading the code).
Closes https://github.com/astral-sh/uv/issues/12753.
## Summary
See the test cases. Previously, you could end up with something like:
```toml
[tool.uv.workspace]
members = [
"foo",
"bar",
"baz", "bop",
]
```
<!--
Thank you for contributing to uv! To help us out with reviewing, please
consider the following:
- Does this pull request include a summary of the change? (See below.)
- Does this pull request include a descriptive title?
- Does this pull request include references to any relevant issues?
-->
## Summary
Fixes#12606.
Two options considered, thanks to @zanieb's guidance are:
1. Special-casing on parse error and encountering the `environment.yml`
filename, possibly at `RequirementsTxt::parse`
2. Adding a new `RequirementsSource::EnvironmentYml` variant and
erroring on `RequirementSpecification::from_source`
I went with the latter for the following reasons:
- This edge case is explicitly modelled within the type system. However,
it changes the semantics of `RequirementsSource` to also model
_unsupported_ sources.
- (**Separation of concerns**) The special-casing would occur in the
`uv-requirements-txt` crate, which seems to be relatively deep in the
guts of the codebase. In my opinion, maintainers working in
`uv-requirements-txt` would reasonably assume the input file to be a
`requirements.txt` file, instead of having to be concerned with it being
another file format (`environment.yml`, `pyproject.toml`, etc.)
<!-- What's the purpose of the change? What does it do, and why? -->
## Test Plan
Manually tested as follows:
```sh
>>> cargo run -- pip install -r environment.yml
error: Conda environment file `environment.yml` is not supported
>>> cargo run -- add -r environment.yml
error: Conda environment file `environment.yml` is not supported
```
If you can point me to the appropriate test module, I can write up tests
for these to use `insta`.
<!-- How was it tested? -->
## Summary
Add an option to overwrite the list of available Python downloads from a
local JSON file by using the environment variable
`UV_PYTHON_DOWNLOADS_JSON_URL`
as an experimental support for providing custom sources for Python
distribution binaries #8015
related #10203
I probably should make the JSON to be fetched from a remote URL instead
of a local file.
please let me know what you think and I will modify the code
accordingly.
## Test Plan
### normal run
```
root@75c66494ba8b:/# /code/target/release/uv python list
cpython-3.14.0a4+freethreaded-linux-x86_64-gnu <download available>
cpython-3.14.0a4-linux-x86_64-gnu <download available>
cpython-3.13.1+freethreaded-linux-x86_64-gnu <download available>
cpython-3.13.1-linux-x86_64-gnu <download available>
cpython-3.12.8-linux-x86_64-gnu <download available>
cpython-3.11.11-linux-x86_64-gnu <download available>
cpython-3.10.16-linux-x86_64-gnu <download available>
cpython-3.9.21-linux-x86_64-gnu <download available>
cpython-3.8.20-linux-x86_64-gnu <download available>
cpython-3.7.9-linux-x86_64-gnu <download available>
pypy-3.10.14-linux-x86_64-gnu <download available>
pypy-3.9.19-linux-x86_64-gnu <download available>
pypy-3.8.16-linux-x86_64-gnu <download available>
pypy-3.7.13-linux-x86_64-gnu <download available>
```
### empty JSON file
```sh
root@75c66494ba8b:/# export UV_PYTHON_DOWNLOADS_JSON_URL=/code/crates/uv-python/my-download-metadata.json
root@75c66494ba8b:/# cat $UV_PYTHON_DOWNLOADS_JSON_URL
{}
root@75c66494ba8b:/# /code/target/release/uv python list
root@75c66494ba8b:/#
```
### JSON file with valid version
```sh
root@75c66494ba8b:/# export UV_PYTHON_DOWNLOADS_JSON_URL=/code/crates/uv-python/my-download-metadata.json
root@75c66494ba8b:/# cat $UV_PYTHON_DOWNLOADS_JSON_URL
{
"cpython-3.11.9-linux-x86_64-gnu": {
"name": "cpython",
"arch": {
"family": "x86_64",
"variant": null
},
"os": "linux",
"libc": "gnu",
"major": 3,
"minor": 11,
"patch": 9,
"prerelease": "",
"url": "20240814/cpython-3.11.9%2B20240814-x86_64-unknown-linux-gnu-install_only_stripped.tar.gz",
"sha256": "daa487c7e73005c4426ac393273117cf0e2dc4ab9b2eeda366e04cd00eea00c9",
"variant": null
}
}
root@75c66494ba8b:/# /code/target/release/uv python list
cpython-3.11.9-linux-x86_64-gnu <download available>
root@75c66494ba8b:/#
```
### Remote Path
```sh
root@75c66494ba8b:/# export UV_PYTHON_DOWNLOADS_JSON_URL=http://a.com/file.json
root@75c66494ba8b:/# /code/target/release/uv python list
error: Remote python downloads JSON is not yet supported, please use a local path (without `file://` prefix)
```
---------
Co-authored-by: Aria Desires <aria.desires@gmail.com>
## Summary
closes#12234
[fetch_with_cli](e0f81f0d4a/crates/uv-git/src/git.rs (L573))
doesn't respect the registry client's [connectivity
setting](e0f81f0d4a/crates/uv-client/src/registry_client.rs (L1009))
- this pr updates `fetch_with_cli` to set `GIT_ALLOW_PROTOCOL=file` when
the client's connectivity setting is `Connectivity::Offline`
## Test Plan
E2E
```sh
cargo run add "pycurl @ git+https://github.com/pycurl/pycurl.git" --directory ~/src/offline-test/ --offline
```
```sh
Compiling uv-cli v0.0.1 (/Users/justinchapman/src/uv/crates/uv-cli)
Compiling uv v0.6.11 (/Users/justinchapman/src/uv/crates/uv)
Finished `dev` profile [unoptimized + debuginfo] target(s) in 4.47s
Running `target/debug/uv add 'pycurl @ git+https://github.com/pycurl/pycurl.git' --directory /Users/justinchapman/src/offline-test/ --offline`
Updating https://github.com/pycurl/pycurl.git (HEAD) × Failed to download and build `pycurl @ git+https://github.com/pycurl/pycurl.git`
├─▶ Git operation failed
├─▶ failed to fetch into: /Users/justinchapman/.cache/uv/git-v0/db/9a596e5213c3162d
╰─▶ process didn't exit successfully: `/usr/bin/git fetch --force --update-head-ok 'https://github.com/pycurl/pycurl.git' '+HEAD:refs/remotes/origin/HEAD'` (exit status: 128)
--- stderr
fatal: transport 'https' not allowed
help: If you want to add the package regardless of the failed resolution, provide the `--frozen` flag to skip locking and syncing.
```
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
