<!--
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
There were no GraalPy binary wheels were available when uv support was
added, and thus the abi tag was never tested against actual packages.
Now that GraalPy publishes binary wheels to
https://www.graalvm.org/python/wheels/ we noticed the abi tag was
incorrect and the version info incorrectly determined.
## Test Plan
I tested manually:
```
> target/debug/uv venv --python graalpy testvenv
Using GraalPy 3.11.7 interpreter at: /home/tim/.pyenv/versions/graalpy-24.1.1/bin/graalpy
Creating virtual environment at: testvenv
Activate with: source testvenv/bin/activate
> cat <<EOF> uv.toml
> [[index]]
> url = "https://www.graalvm.org/python/wheels/"
> EOF
> target/debug/uv -v pip install psutil
warning: Found both a `uv.toml` file and a `[tool.uv]` section in an adjacent `pyproject.toml`. The `[tool.uv]` section will be ignored in favor of the `uv.toml` file.
DEBUG uv 0.6.6+3 (be8725553 2025-03-13)
DEBUG Searching for default Python interpreter in virtual environments
DEBUG Found `graalpy-3.11.7-linux-x86_64-gnu` at `/home/tim/dev/uv/.venv/bin/python3` (virtual environment)
DEBUG Using Python 3.11.7 environment at: .venv
DEBUG Acquired lock for `.venv`
DEBUG At least one requirement is not satisfied: psutil
DEBUG Using request timeout of 30s
DEBUG Solving with installed Python version: 3.11.7
DEBUG Solving with target Python version: >=3.11.7
DEBUG Adding direct dependency: psutil*
DEBUG Found fresh response for: https://www.graalvm.org/python/wheels/psutil/
DEBUG Searching for a compatible version of psutil (*)
DEBUG Selecting: psutil==5.9.8 [compatible] (psutil-5.9.8-graalpy311-graalpy241_311_native-manylinux_2_12_x86_64.manylinux2010_x86_64.manylinux_2_28_x86_64.whl)
DEBUG No cache entry for: https://gds.oracle.com/download/graalpy-wheels/psutil-5.9.8-graalpy311-graalpy241_311_native-manylinux_2_12_x86_64.manylinux2010_x86_64.manylinux_2_28_x86_64.whl
DEBUG Tried 1 versions: psutil 1
DEBUG marker environment resolution took 0.968s
Resolved 1 package in 971ms
DEBUG Identified uncached distribution: psutil==5.9.8
DEBUG No cache entry for: https://gds.oracle.com/download/graalpy-wheels/psutil-5.9.8-graalpy311-graalpy241_311_native-manylinux_2_12_x86_64.manylinux2010_x86_64.manylinux_2_28_x86_64.whl
Prepared 1 package in 268ms
Installed 1 package in 28ms
+ psutil==5.9.8
DEBUG Released lock at `/home/tim/dev/uv/.venv/.lock`
```
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
<!--
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
Update this example snippet adding test.pypi.org as a publishing index
to mark the index with `explicit = true`. This will help prevent users
from unexpected behavior if no other indices are defined and users don't
select a different index selection algorithm (with `--index-strategy`).
When `test.pypi.org` is the selected index for package management,
packages resolve to odd versions like 0.0.1 and `uv` spits out lots of
errors.
<!-- What's the purpose of the change? What does it do, and why? -->
## Test Plan
N/A, documentation only change
<!-- How was it tested? -->
In #10669, a pyproject.toml with requires-python but no environment had
a lockfile covering only a subset of the requires-python space:
```toml
resolution-markers = [
"python_full_version >= '3.10' and platform_python_implementation == 'CPython'",
"python_full_version == '3.9.*'",
"python_full_version < '3.9'",
]
```
This marker set is invalid, we have to reject the lockfile. (We can
still use the versions though, to avoid churn).
Part 1/2 of #10669
These changes add support for
```
uv python pin 3.12 --global
```
This adds the specified version to a `.python-version` file in the
user-level config directory. uv will now use the user-level version as a
fallback if no version is found in the project directory or its
ancestors.
Closes#4972
When making changes to uv that require new (or altered) settings, there
are many places in the code that need to change. This slows down work,
reduces confidence in changes for new developers, and adds noise to PRs.
The goal of this PR is to reduce the number of points that need to
change (and that the developer needs to understand) when making changes
to settings.
This PR consolidates `ResolverSettings` and `ResolverInstallerSettings`
by factoring out the shared settings and using a new field
`resolver_settings` on `ResolverInstallerSettings`. This not only
reduces repetition, but makes it easier for a human to parse the code
without having to compare long lists of fields to spot differences (the
difference was that `ResolverInstallerSettings` had two extra fields).
This also removes `ResolverSettingsRef` and
`ResolverInstallerSettingsRef`, using normal Rust references instead.
For the time being, I've left `InstallerSettingsRef` in place because it
appears to have a semantic meaning that might be relied upon. However,
it would now be straightforward to refactor to pass
`&ResolverInstallerSettings` wherever `InstallerSettingsRef` appears,
further reducing sprawl.
The change has the downside of adding
`settings.resolver_settings.<field>` and requiring dereferencing at
various points where it was not required before (with the *SettingsRef
approach). But this means there are significantly fewer places that must
change to update settings.
I think it's important for the breaking changes to be at the _top_ of
the file instead of the bottom.
Now that it's not being rendered by GitHub's Releases markdown, we can
remove the prettier ignores.
Following the upstream release and #12120, removes gating preventing
installation of the managed musl Python versions.
Of note
- The filtering of musl Python distributions has moved from the Rust
runtime to the metadata fetcher
- The filtering is now conditional on the PBS release date, removing all
old static musl distributions
- We could support the `+static` musl downloads in the future; right
now, they are deprioritized when selecting a variant
- I added test to CI which uses Alpine and installs numpy
<!--
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
This PR is meant to fix issue #11862
It allows to send sized bodies during `publish`
<!-- What's the purpose of the change? What does it do, and why? -->
## Test Plan
the PR was tested on the MRE from #11862
<!-- How was it tested? -->
<!--
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
The command `uv python find >=3.11` doesn't work . The version should be
quoted otherwise the terminal interprets the `>` and pipes output to a
file named `=3.11`. I've used single quotes as used on line 90 of this
file.
## Test Plan
Locally
## Summary
Follow up to https://github.com/astral-sh/uv/pull/11888 with added
support for uv tool run.
Changes
* Added functionality for running windows scripts in previous PR was
moved from run.rs to uv_shell::runnable.
* EXE was added as a supported type, this simplified integration across
both uv run and uvx while retaining a backwards compatible behavior and
properly prioritizing .exe over others. Name was adjusted to runnable as
a result to better represent intent.
## Test Plan
New tests added.
## Documentation
Added new documentation.
Reduce the overhead of `uv run` in large workspaces. Instead of
re-discovering the entire workspace each time we resolve the metadata of
a member, we can the discovered set of workspace members. Care needs to
be taken to not cache the discovery for `uv init`, `uv add` and `uv
remove`, which change the definitions of workspace members.
Below is apache airflow e3fe06382df4b19f2c0de40ce7c0bdc726754c74 `uv run
python` with a minimal payload. With this change, we avoid a ~350ms
overhead of each `uv run` invocation.
```
$ hyperfine --warmup 2 \
"uv run --no-dev python -c \"print('hi')\"" \
"uv-profiling run --no-dev python -c \"print('hi')\""
Benchmark 1: uv run --no-dev python -c "print('hi')"
Time (mean ± σ): 492.6 ms ± 7.0 ms [User: 393.2 ms, System: 97.1 ms]
Range (min … max): 482.3 ms … 501.5 ms 10 runs
Benchmark 2: uv-profiling run --no-dev python -c "print('hi')"
Time (mean ± σ): 129.7 ms ± 2.5 ms [User: 105.4 ms, System: 23.2 ms]
Range (min … max): 126.0 ms … 136.1 ms 22 runs
Summary
uv-profiling run --no-dev python -c "print('hi')" ran
3.80 ± 0.09 times faster than uv run --no-dev python -c "print('hi')"
```
The profile after those change below. We still spend a large chunk in
toml parsing (both `uv.lock` and `pyproject.toml`), but it's not
excessive anymore.
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [reflink-copy](https://redirect.github.com/cargo-bins/reflink-copy) |
workspace.dependencies | patch | `0.1.24` -> `0.1.25` |
---
### Release Notes
<details>
<summary>cargo-bins/reflink-copy (reflink-copy)</summary>
###
[`v0.1.25`](https://redirect.github.com/cargo-bins/reflink-copy/blob/HEAD/CHANGELOG.md#0125---2025-03-08)
[Compare
Source](https://redirect.github.com/cargo-bins/reflink-copy/compare/v0.1.24...v0.1.25)
##### Other
- Bump rustix from 0.38.34 to 1.0.1
([#​101](https://redirect.github.com/cargo-bins/reflink-copy/pull/101))
</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:eyJjcmVhdGVkSW5WZXIiOiIzOS4xODUuNCIsInVwZGF0ZWRJblZlciI6IjM5LjE4NS40IiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJpbnRlcm5hbCJdfQ==-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Adds a new optional key `auth-policy` to `[tool.uv.index]` that sets the
authentication policy for the index URL.
The default is `"auto"`, which attempts to authenticate when necessary.
`"always"` always attempts to authenticate and fails if the endpoint is
unauthenticated. `"never"` never attempts to authenticate.
These policy address two kinds of cases:
* Some indexes don’t fail on unauthenticated requests; instead they just
forward to the public PyPI. This can leave the user confused as to why
their package is missing. The "always" policy prevents this.
* "never" allows users to ensure their credentials couldn't be leaked to
an unexpected index, though it will only allow for successful requests
on an index that doesn't require credentials.
Closes#11600
In the publish client, we have to set the client retries to 0 as the
retry middleware is incompatible with upload bodies. This however also
sets `client.retry_policy()` to a zero-retry policy, so we need to
construct our own policy.
Fixes#12027
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
This PR moves functions for finding user- and system-level config
directories to public functions in `uv_fs::config`. This will allow them
to be used in future work without duplicating code.
This adds support for inferring dependency group conflict sets from the
directly defined conflicts in configuration. For example, if you declare
a conflict between groups `alpha` and `beta` and `dev` includes `beta`,
then we will infer a conflict between `dev` and `alpha`. We will also
handle a conflict between two groups if they transitively include groups
that conflict with each other. See #11232 for more details.
Closes#11232
## Summary
<!-- What's the purpose of the change? What does it do, and why? -->
The way the `tool update-shell` checks if the command to export the PATH
exists or not in the RC files is a blind search, and therefore if finds
the command inside comments.
example with .zshenv
This content
```
# uv
# export PATH="/Users/cholas/.local/bin:$PATH"
```
Generates the following msg
```
error: The executable directory /Users/cholas/.local/bin is not in PATH, but the Zsh configuration files are already up-to-date
```
With this change, that content won't be considered as configured and the
following will be added
```
# uv
export PATH="/Users/cholas/.local/bin:$PATH"
```
This will make the `update-shell` more reliable
## Test Plan
I tested with and without the change with commented export in zsh in
mac. Tested running `cargo run -- tool update-shell`
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
I somehow missed running an actual integration test of the PEP 517 API
in CI and the python shim was using the old uv CLI interface still.
The tests include pip, uv and `python -m build`. They must be a in CI
job since we can't depend on the Python package in the Rust tests (we
only get the binary in `cargo test`, not the `uv_build` wheel).
## Summary
The order here is slightly off... As-is, we fetch the metadata for the
dependency, _then_ insert the URLs and indexes into the fork state -- so
the fetch doesn't take the explicit index or URL into account. This has
mostly been unobserved because we re-fetch anyway in the next request,
but if we do things in the right order (add to fork state, fetch
dependencies, insert dependencies), we can cut down on the fetches.
Closes https://github.com/astral-sh/uv/issues/12056.
Thank you for uv, it has game-changer capabilities in the field of
Python package and environment maangement!
## Summary
This is a small PR adding the option `module-name`
(`tool.uv.build-backend.module-name`) to the uv build backend (
https://github.com/astral-sh/uv/issues/8779 ).
Currently, the uv build backend will assume that the module name matches
the (dash to underdash-transformed) package name. In some packaging
scenarios this is not the case, and currently there exists no
possibility to override it, which this PR addresses.
From the main issue ( https://github.com/astral-sh/uv/issues/8779 ) I
could not tell if there is any extensive roadmap or plans how to
implement more complex scenarios, hence this PR as a suggestion for a
small feature with a big impact for certain scenarios.
I am new to Rust, I hope the borrow/reference usage is correct.
## Test Plan
So far I tested this at an example, if desired I can look into extending
the tests.
Fixes#11428
---------
Co-authored-by: konstin <konstin@mailbox.org>
This PR is in support of #12005, where we need to import
`DependencyGroups` in the `uv-pypi-types` crate without a circular
dependency on `uv-workspace`.
