This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
|
[acj/freebsd-firecracker-action](https://redirect.github.com/acj/freebsd-firecracker-action)
| action | minor | `v0.3.0` -> `v0.4.0` |
---
> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.
---
### Release Notes
<details>
<summary>acj/freebsd-firecracker-action
(acj/freebsd-firecracker-action)</summary>
###
[`v0.4.0`](https://redirect.github.com/acj/freebsd-firecracker-action/releases/tag/v0.4.0)
[Compare
Source](https://redirect.github.com/acj/freebsd-firecracker-action/compare/v0.3.0...v0.4.0)
[Firecracker
1.12.0](https://redirect.github.com/firecracker-microvm/firecracker/releases/tag/v1.12.0)
[FreeBSD 14.3-STABLE](https://www.freebsd.org/releases/14.3R/relnotes/)
Bug fixes:
- Wait for Firecracker VM to exit before returning control to the
calling workflow
Changes:
- Upgrade CI workflow to Ubuntu 24.04
</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:eyJjcmVhdGVkSW5WZXIiOiI0MC4xNi4wIiwidXBkYXRlZEluVmVyIjoiNDAuMTYuMCIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiaW50ZXJuYWwiXX0=-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
This one claims in its README to resolve segfaults.
Also sync the commented-out workflow to match the uncommented ones.
## Test Plan
Checks passed in #13600 already....
## Summary
Now that Python 3.14 first beta is out, I think it's worth adding
support for the official upstream RC images.
Once 3.14 is released, we can remove the `-rc-` infix from the images we
pull from.
## Test Plan
Upstream images verified to be functional with uv.
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| fedora | container | major | `42` -> `43` |
---
### 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:eyJjcmVhdGVkSW5WZXIiOiIzOS4yNTcuMyIsInVwZGF0ZWRJblZlciI6IjM5LjI1Ny4zIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJpbnRlcm5hbCJdfQ==-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.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
<!-- What's the purpose of the change? What does it do, and why? -->
This PR updates the issue templates to recommend using the `uv self
version` command instead of `uv version` for retrieving uv's own version
information. The `uv version` command is intended to show the current
project's version (from pyproject.toml), not the uv tool version, which
leads to confusion when users try to report issues.
## Test Plan
<!-- How was it tested? -->
n/a
## Summary
This adds GraalPy download metadata so that `uv python install graalpy`
works. See https://github.com/astral-sh/uv/issues/13114
## Test Plan
The existing integration test was changed to test this functionality.
#5577 fixed a bug on macos due to dynamically linking lzma/xz through
static linking. In #7686, this feature was moved to the performance
category.
This PR moves the `xz2/static` back to the general default features,
and, inspired by https://github.com/Homebrew/homebrew-core/pull/222211,
it structures and documents the feature flags cleaner.
We need to take care that this feature does not accidentally disable
features we want.
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
## Summary
In #10939 I added the generated
`crates/uv-python/src/download-metadata-minified.json` file which is a
minified version of `crates/uv-python/download-metadata.json`.
The main reason for this PR is to avoid bloating the git objects as this
is a single-line file.
As a bonus, I also filtered the embed json to include only the versions
for the compiled target. Which should improve the binary size and
performance by a bit.
## Test Plan
<!-- How was it tested? -->
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [astral-sh/setup-uv](https://redirect.github.com/astral-sh/setup-uv) |
action | major | `v5.4.2` -> `v6.0.0` |
---
### Release Notes
<details>
<summary>astral-sh/setup-uv (astral-sh/setup-uv)</summary>
###
[`v6.0.0`](https://redirect.github.com/astral-sh/setup-uv/releases/tag/v6.0.0):
🌈 activate-environment and working-directory
[Compare
Source](https://redirect.github.com/astral-sh/setup-uv/compare/v5.4.2...v6.0.0)
##### Changes
This version contains some breaking changes which have been gathering up
for a while. Lets dive into them:
- [Activate environment](#activate-environment)
- [Working Directory](#working-directory)
- [Default `cache-dependency-glob`](#default-cache-dependency-glob)
- [Use default cache dir on self hosted
runners](#use-default-cache-dir-on-self-hosted-runners)
##### Activate environment
In previous versions using the input `python-version` automatically
activated a venv at the repository root.
This led to some unwanted side-effects, was sometimes unexpected and not
flexible enough.
The venv activation is now explicitly controlled with the new input
`activate-environment` (false by default):
```yaml
- name: Install the latest version of uv and activate the environment
uses: astral-sh/setup-uv@v6
with:
activate-environment: true
- run: uv pip install pip
```
The venv gets created by the [`uv
venv`](https://docs.astral.sh/uv/pip/environments/) command so the
python version is controlled by the `python-version` input or the files
`pyproject.toml`, `uv.toml`, `.python-version` in the
`working-directory`.
##### Working Directory
The new input `working-directory` controls where we look for
`pyproject.toml`, `uv.toml` and `.python-version` files
which are used to determine the version of uv and python to install.
It can also be used to control where the venv gets created.
```yaml
- name: Install uv based on the config files in the working-directory
uses: astral-sh/setup-uv@v6
with:
working-directory: my/subproject/dir
```
> \[!CAUTION]
>
> The inputs `pyproject-file` and `uv-file` have been removed.
##### Default `cache-dependency-glob`
[@​ssbarnea](https://redirect.github.com/ssbarnea) found out that
the default `cache-dependency-glob` was not suitable for a lot of users.
The old default
```yaml
cache-dependency-glob: |
**/requirements*.txt
**/uv.lock
```
is changed and should cover over 99.5% of use cases:
```yaml
cache-dependency-glob: |
**/*(requirements|constraints)*.(txt|in)
**/pyproject.toml
**/uv.lock
```
> \[!NOTE]
>
> This shouldn't be a breaking change. The only thing you may notice is
that your caches get invalidated once.
##### Use default cache dir on self hosted runners
The directory where uv stores its cache was always set to a directory in
`RUNNER_TEMP`. For self-hosted runners this made no sense as this gets
cleaned after every run and led to slower runs than necessary.
On self-hosted runners `UV_CACHE_DIR` is no longer set and the [default
cache
directory](https://docs.astral.sh/uv/concepts/cache/#cache-directory) is
used instead.
##### 🚨 Breaking changes
- Change default cache-dependency-glob
[@​eifinger](https://redirect.github.com/eifinger)
([#​352](https://redirect.github.com/astral-sh/setup-uv/issues/352))
- No default UV_CACHE_DIR on selfhosted runners
[@​eifinger](https://redirect.github.com/eifinger)
([#​380](https://redirect.github.com/astral-sh/setup-uv/issues/380))
- new inputs activate-environment and working-directory
[@​eifinger](https://redirect.github.com/eifinger)
([#​381](https://redirect.github.com/astral-sh/setup-uv/issues/381))
##### 🧰 Maintenance
- chore: update known checksums for 0.6.16
@​[github-actions\[bot\]](https://redirect.github.com/apps/github-actions)
([#​378](https://redirect.github.com/astral-sh/setup-uv/issues/378))
- chore: update known checksums for 0.6.15
@​[github-actions\[bot\]](https://redirect.github.com/apps/github-actions)
([#​377](https://redirect.github.com/astral-sh/setup-uv/issues/377))
##### 📚 Documentation
- bump to v6 in README
[@​eifinger](https://redirect.github.com/eifinger)
([#​382](https://redirect.github.com/astral-sh/setup-uv/issues/382))
- log info on venv activation
[@​eifinger](https://redirect.github.com/eifinger)
([#​375](https://redirect.github.com/astral-sh/setup-uv/issues/375))
</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:eyJjcmVhdGVkSW5WZXIiOiIzOS4yNTcuMyIsInVwZGF0ZWRJblZlciI6IjM5LjI1Ny4zIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJpbnRlcm5hbCJdfQ==-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Putting this up to confirm that it does what it should:
* undirty the release.yml by including action-commits in the config
* add `persist-credentials=false` hardening
* includes but does not use `[package.metadata.dist.binaries]` overrides
(for #11786)
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
|
[taiki-e/install-action](https://redirect.github.com/taiki-e/install-action)
| action | digest | `6aca1cf` -> `2db3465` |
---
### 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:eyJjcmVhdGVkSW5WZXIiOiIzOS4yMjcuMyIsInVwZGF0ZWRJblZlciI6IjM5LjIzNS4yIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJpbnRlcm5hbCJdfQ==-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
## 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": "https://github.com/astral-sh/python-build-standalone/releases/download/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>
I wanted to consolidate these anyway, and apparently it's a huge pain to
make a Windows task fail early via GitHub's PowerShell setup so I
implement this in Python instead.
The i686 linux gnu release job started failing since the last release
(#12430) due to an OOM with llvm breaking the 4GB limit for 32-bit
processes. We work around this by using a 64-bit host targeting 32-bit.
## Summary
The intent here is that all actions should be pinned to an immutable SHA
(but that Renovate should annotate each SHA with the corresponding
SemVer version).
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
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).
uv itself is a large package with many dependencies and lots of
features. To build a package using the uv build backend, you shouldn't
have to download and install the entirety of uv. For platform where we
don't provide wheels, it should be possible and fast to compile the uv
build backend. To that end, we're introducing a python package that
contains a trimmed down version of uv that only contains the build
backend, with a minimal dependency tree in rust.
The `uv_build` package is publish from CI just like uv itself. It is
part of the workspace, but has much less dependencies for its own
binary. We're using cargo deny to enforce that the network stack is not
part of the dependencies. A new build profile ensure we're getting the
minimum possible binary size for a rust binary.
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
I noticed that https://github.com/astral-sh/uv/pull/11936 did not run
the Docker builds, nor did #11934
We should run these when the relevant files change so there aren't
surprises at release time!
Updates the `build-binaries` workflow to include toolchain version
changes and `.cargo/config.toml` changes too.
For uv-build, we need to duplicate a lot of the `build-binaries.yml`
logic to build another source distribution and wheel. In preparation for
that I tried to make the invocations more consistent, to make it easier
to review the changes when adding the `uv-build` builds on top.
Split out from #11446
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
Alpine 3.21 has been released for a few months and it's now being used
officially under `alpine` based [python
images](https://hub.docker.com/_/python), hence our python-alpine based
images has been using 3.21 since uv 0.5.8 under the hood.
This could arguably be `breaking` as we're dropping alpine3.20 top-level
tag, so it could be a good candidate for 0.6.0.
Alternatively, we can keep support for 3.20 and make this non-breaking
by simply repointing alpine to now be 3.21 and keeping the 3.20 tag
around.
cosign uses the GitHub action ID token to retrieve an ephemeral code
signing certificate from Fulcio, and store the signature in the Rekor
transparency log.
Once an image has been successfully signed, you should be able to verify
the signature with:
```sh
cosign verify ghcr.io/astral-sh/uv:latest --certificate-identity-regexp='.*' --certificate-oidc-issuer-regexp='.*'
```
Closes#8670
We have a lot of jobs downstream of the `build-binary-linux` job, but
the job is significantly slower than the other binary builds because we
need to configure musl. Instead, we split this into two jobs (as it was
before https://github.com/astral-sh/uv/pull/2309#discussion_r1520101330)
to speed things up.
The libc job takes ~1m and its _downstream_ jobs finish before the musl
build does. The musl job takes ~5m.
## Summary
In preview mode on windows, register und un-register the managed python build standalone installations in the Windows registry following PEP 514.
We write the values defined in the PEP plus the download URL and hash. We add an entry when installing a version, remove an entry when uninstalling and removing all values when uninstalling with `--all`. We update entries only by overwriting existing values, there is no "syncing" involved.
Since they are not official builds, pbs gets a prefix. `py -V:Astral/CPython3.13.1` works, `py -3.13` doesn't.
```
$ py --list-paths
-V:3.12 * C:\Users\Konsti\AppData\Local\Programs\Python\Python312\python.exe
-V:3.11.9 C:\Users\Konsti\.pyenv\pyenv-win\versions\3.11.9\python.exe
-V:3.11 C:\Users\micro\AppData\Local\Programs\Python\Python311\python.exe
-V:3.8 C:\Users\micro\AppData\Local\Programs\Python\Python38\python.exe
-V:Astral/CPython3.13.1 C:\Users\Konsti\AppData\Roaming\uv\data\python\cpython-3.13.1-windows-x86_64-none\python.exe
```
Registry errors are reported but not fatal, except for operations on the company key since it's not bound to any specific python interpreter.
On uninstallation, we prune registry entries that have no matching Python installation (i.e. broken entries).
The code uses the official `windows_registry` crate of the `winreg` crate.
Best reviewed commit-by-commit.
## Test Plan
We're reusing an existing system check to test different (un)installation scenarios.
In the interest of expanding these tests and debugging weird behaviors,
I've moved the smoke tests out of the `cargo test` job and into
dedicated `smoke test` jobs. We explicitly build `uvx` in the `build
binary` jobs instead of relying on the implicit build for the test run.
I also added a `uvx` test case to the smoke tests: `uvx ruff --version`
Demo at https://github.com/zanieb/uv/issues
I think the next steps are to
- Move the "Build failures" document to a dedicated "Troubleshooting"
section
- Add more documentation on how to create an MRE
- Add more troubleshooting pages
See https://github.com/astral-sh/uv/issues/4204 for motivation
This doesn't really reach the user experience I'd expect — i.e., we end
up saying a virtual environment "does not exist" which is a little
silly. However, I think improving the error messaging on interpreter
queries in general should be solved separately. I did one small
"general" change in
89e11d0222
— otherwise we don't show the message at all.
---------
Co-authored-by: konsti <konstin@mailbox.org>
When using the standard Windows runners (as opposed to the _larger_
GitHub runners), an undocumented `D:` drive is available and performant.
We can save some money on by using this on a standard runner instead of
a larger runner with an ReFS drive. Switching to the `D:` drive was not
acceptable for `cargo test` >25m runtime.
Inspired by https://github.com/pypa/pip/pull/13129
See https://github.com/actions/runner-images/issues/8755
Timings (grain of salt — GitHub is super noisy):
- clippy: 2m 18s -> 2m 11s
- build binary: 2m 3s -> 2m 35s
- trampoline check (x86-64): 2m 32s -> 1m 50s (other architectures
similar)
- trampoline test (x86-64): 4m 12s -> 6m 7s
- trampoline test (i686): 6m 44s -> 5m 35s
Previously, we couldn't use a DevDrive
(https://github.com/astral-sh/uv/pull/3522#issuecomment-2111448930)
because our Windows version was not sufficient.
Recently, I upgraded our larger runners to Windows 2025 preview
(https://github.com/astral-sh/uv/pull/10298) which I presume has support
for this.
I removed ReFS in
953c3535c3
which didn't seem to do anything to performance.
I also found some notes on "trusted" DevDrives and "disabling anti-virus
filtering" which I simply have to try.
The latest release flaked failing to fetch the buildx image, which is
reportedly due to rate limits. Last I checked, DockerHub enforces much
stricter limits on unauthenticated requests. I added a bot account and a
corresponding read-only token.
The shellcheck action we uses misses some files, so they fell out of
spec for what we support. This PR first and foremost adds them to the
scanning list, and then fixes the issues found.
Fixes#7480
I'm renaming our runners to be more explicit about their size,
architecture, and version.
Switching to Windows 2025 over 2022 in some of our jobs in the hope that
it's faster.
Enable `lzma-sys/static` through the performance feature not only in uv,
but in uv-dev and uv-bench too, to avoid the system dependency on
`liblzma-dev`.
Ref #9880
## Summary
This is blocking the release (#9793). We seem to have hit some sort of
limit that's causing builds to fail on this target. It's a Tier 3 Rust
target with _unknown_ (???) `std` support (see the question mark
[here](https://doc.rust-lang.org/rustc/platform-support.html)).
When trying to upload without a password but with the keyring, check
that the keyring has a password for the upload URL and username and warn
if it doesn't.
Fixes#8781
## Summary
In the Windows Clippy job, the workspace is transferred to
`UV_WORKSPACE`. However, `cargo clippy` continues to execute in the
`github.workspace`, and `Swatinem/rust-cache` only caches the
`UV_WORKSPACE/target`, resulting in `cargo clippy` having no cache.
This adjustment will take effect when any changes are made to
`Cargo.toml` or `Cargo.lock`, prompting `Swatinem/rust-cache` to updat
the cache.
Incorporating #8637 into #8458
- Adds `python-managed` feature selection to Windows CI for `python
install` tests
- Adds trampoline sniffing utilities to `uv-trampoline-builder`
- Uses a trampoline to install Python executables into the `PATH` on
Windows
Updates `uv python install` to link `python3.x` in the executable
directory (i.e., `~/.local/bin`) to the the managed interpreter path.
Includes
- #8569
- #8571
Remaining work
- #8663
- #8650
- Add an opt-out setting and flag
- Update documentation
Currently, our trampoline is used to convert `<command> [args]` to
`python <command> [args]` for script entrypoints installed into virtual
environments. For #8458, it'd be nice to convert a shim `python3.12
[args]` to `python [args]`. Here, we modify the trampolines to support
this use-case.
The only change we really need here is to avoid injecting `<command>`
into the child process. We change the "magic number" at the end of the
trampoline executables from `UVUV` to `UVSC` and `UVPY` which define
"script" and "python" variants to the trampoline. We then omit the
`<command>` injection in the latter case. We also omit writing the zip
script payload.
To support construction of the new variant, a new
`uv-trampoline-builder` crate is introduced — this avoids requirements
on `uv-install-wheel` in future work. I also use `uv-trampoline-builder`
to consolidate some of the test setup for `uv-trampoline`.
There should be no backwards compatibility concerns, since trampolines
are fully self-referential.
I rebased to fix the commits at the end, as this took many iterations to
get working via CI. This should roughly be reviewable by commit if you
prefer.
It seems unintentional that we basically did nothing on these
alternative platforms? It seems like an artifact from some previous
change.
I'm not sure it's worth running Clippy multiple times. We could also
just reduce the matrix here.
Cherry-picked from #8347
Might fix https://github.com/astral-sh/uv/issues/6940 — I'm not seeing a
failure over there after this change. I think there may be some problem
with concurrent reads of junctioned files on the DevDrive? It's really
hard to say.
We might lose some important test coverage with this change. I'm not
sure what to do about that either.
Closes https://github.com/astral-sh/uv/issues/8228
e.g., on this branch
```
❯ uv python install 3.13t 3.13
❯ cargo build
❯ cargo run -q --bin uvx -- --from build python -c "import sys; print(sys.base_prefix)"
/Users/zb/.local/share/uv/python/cpython-3.13.0-macos-aarch64-none
❯ cargo run -q --bin uvx -- -p 3.13 --from build python -c "import sys; print(sys.base_prefix)"
/Users/zb/.local/share/uv/python/cpython-3.13.0-macos-aarch64-none
❯ cargo run -q --bin uvx -- -p 3.13t --from build python -c "import sys; print(sys.base_prefix)"
/Users/zb/.local/share/uv/python/cpython-3.13.0+freethreaded-macos-aarch64-none
```
and on main
```
❯ cargo build
❯ cargo run -q --bin uvx -- --from build python -c "import sys; print(sys.base_prefix)"
Installed 3 packages in 12ms
/Users/zb/.local/share/uv/python/cpython-3.13.0+freethreaded-macos-aarch64-none
```
I want to add more test coverage around this, but I've noticed the
free-threaded discovery tests are a bit off as-is and it'll be a bigger
task. I think the recent bugs around discovery indicate we should invest
more into that test framework.
## Summary
Reverts #8181 and #8182.
The fix is in b849f0f, which extends the run timeout to allow xwin to
download the Windows SDK files, which can take 10+ minutes.
Closes https://github.com/rust-cross/cargo-xwin/issues/127
## Test Plan
Existing CI should pass.
## Notes
xwin jobs will take a long time the first time due to cache re-warming.
## Summary
Update CI config to test against GraalPy 24.1, which makes a workaround
in the CI config unnecessary.
## Test Plan
The updated CI config is 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
I started learning `uv` by inspecting the source code.
I've noticed that your shell scripts are very good! Which is rare!
## Test Plan
I propose to add `shellcheck` to the CI.
It is a great tool to help finding bugs and style issues in shell code.
Techincal details:
- This CI job will only run when any `.sh` files are changed (or the job
definition file)
- It takes just several seconds even on local machine:
```
» time shellcheck -S style **/*.sh
shellcheck -S style **/*.sh 0.02s user 0.05s system 61% cpu 0.123 total
```
- It is easy to use, for example: I just fixed the single problem you
had in your code with `# shellcheck disable=SC1091`
- I am using this tool for around 8 years now and didn't have any
issues. Examples:
ca899f3b69/.github/workflows/test.yml (L22-L27)
and
https://github.com/wemake-services/wemake-django-template/blob/master/.github/workflows/shellcheck.yml
But, I understand that build / lint tools are very subjective. So, feel
free to close :)
## Summary
Closes https://github.com/astral-sh/uv/issues/6972
This is not breaking since `MACOSX_DEPLOYMENT_TARGET` will stay the same
(currently defaulting to 10.12) so a
`uv-x.y.z-py3-none-macosx_10_12_x86_64.whl` will still be built
## Summary
Copy both `uv` and `uvx` into place in a single Dockerfile command.
[`COPY` supports multiple sources when the destination is a
directory.](https://docs.docker.com/engine/reference/builder/#copy)
As it is, e.g. `ghcr.io/astral-sh/uv:0.4.16-python3.12-bookworm-slim`
has this (screenshot from [Dive](https://github.com/wagoodman/dive)):
<img width="377" alt="Screenshot 2024-09-26 at 10 11 24"
src="https://github.com/user-attachments/assets/1ca6a0d5-95fd-4210-9a4f-0afa2300b63f">
and less layers is a Good Thing.
## Test Plan
I hope the CI pipeline will take care of testing – I couldn't get the
Docker build to finish on my machine right away (SIGKILL, so out of
memory, I guess 😄)
<!--
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
closes#4828
First iteration for an implementation. I need to add more tests but
wanted your opinion on the implementation first.
<!-- What's the purpose of the change? What does it do, and why? -->
## Test Plan
Currently tested using the following command but will add tests shortly:
```console
D:\repo\uv> cargo run venv -p 3.13t && .venv\Scripts\python.exe
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.52s
Running `target\debug\uv.exe venv -p 3.13t`
Using Python 3.13.0rc1 interpreter at: C:\Users\bschoen\AppData\Local\Programs\Python\Python313\python3.13t.exe
Creating virtualenv at: .venv
Activate with: .venv\Scripts\activate
Python 3.13.0rc1 experimental free-threading build (tags/v3.13.0rc1:e4a3e78, Jul 31 2024, 21:06:58) [MSC v.1940 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>
```
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
## Summary
Originally wanted to update the reference to `astral-sh/setup-uv` in
https://docs.astral.sh/uv/guides/integration/github/, but thought it
could be nice to automate those updates through Renovate. The custom
manager will look for any major version GitHub Action reference in any
Markdown file in `docs` directory, and raise a PR to update it.
Possible improvements:
- We could separate those updates from updating the actions updates for
uv's own GitHub Actions workflow, which would end up raising 2 different
PRs instead of grouping them (example of the current behaviour without
this improvement in
https://github.com/mkniewallner/mkv-playground/pull/4 where we update
the doc reference at the same time as a real dependency usage in a
workflow).
- ~Should the PRs be raised immediately, to handle the update as soon as
possible, instead of waiting for the regular weekly Monday schedule?
This would ensure that `astral-sh/setup-uv` references are handled as
early as possible.~ done in
6af7f45750
## Test Plan
I've tested that with
00ddfb6900/renovate.json5
and
00ddfb6900/docs/integeration/foo.md,
where Renovate raised 2 PRs:
- https://github.com/mkniewallner/mkv-playground/pull/13
- https://github.com/mkniewallner/mkv-playground/pull/4
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
## Summary
Closes https://github.com/astral-sh/uv/issues/7458
This change adds a new job at the end of docker publish which adds
annotations the primary image digests in order to make ghcr.io rank
`ghcr.io/astral-sh/uv` at the top once again. The solution is to
annotate the index at the end during a re-publish to make ghcr.io
consider it a more updated entry than the others and rank it at the top
once again.
## Test Plan
Tested on release run on my own fork
* Packages: https://github.com/samypr100/uv/pkgs/container/uv will show
`ghcr.io/astral-sh/uv` first once again
* Run: https://github.com/samypr100/uv/actions/runs/10951404736
## Summary
Because a problem was found with Powershell and combining the generated
completion scripts for uv and uvx, let's try separating uv and uvx
command completion scripts.
The generated powershell script template can be seen in clap_complete
source, and it starts with `using` directives, which makes it impossible
(apparently) to concatenate two of those script outputs.
As a side effect, this is available under `uv tool run
--generate-shell-completion` too.
Fixes#7482
## Test Plan
- `eval "$(cargo run --bin uvx -- --generate-shell-completion bash)"`
- Test Powershell
Similar to our semantics for packages with pre-release versions.
We will not use prerelease versions unless there are only prerelease
versions available, a specific version is requested,
or the prerelease version is found in a reasonable source (active
environment, explicit path, etc. but not `PATH`).
For example, `uv python install 3.13 && uv run python --version` will no
longer use `3.13.0rc2` unless that is the only Python version available,
`--python 3.13` is used, or that's the Python version that is present in
`.venv`.
## Summary
Add maturin build flag to set 64kb page size on PPC64 and PPC64LE
architectures. Not aware of modern systems that use 4kb pages.
Resolves#6528
## Test Plan
ppc64le gnu dynamic-linked and musl static-linked binary builds were
tested successfully on an IBM Power9 system running RHEL 8.8. I do not
have access to other types of PPC64 systems for testing.
## Summary
Closes https://github.com/astral-sh/uv/issues/7030
This removes our custom `ENTRYPOINT` just for the additional docker
tags, and makes it empty (to avoid possible upstream surprises if any)
and moves running uv to `CMD` for consistency.
This approach is probably the in-between solution from the discussion in
https://github.com/astral-sh/uv/issues/7030#issuecomment-2329443719 and
would work for everyone's use cases.
## Test Plan
Tested release workflow in
https://github.com/samypr100/uv/actions/runs/10711049920
The default CMD still gives a nice default.
```shell
> docker run ghcr.io/samypr100/uv:0.4.5-alpine
An extremely fast Python package manager.
Usage: uv [OPTIONS] <COMMAND>
Commands:
run Run a command or script
init Create a new project
add Add dependencies to the project
remove Remove dependencies from the project
sync Update the project's environment
lock Update the project's lockfile
export Export the project's lockfile to an alternate format
tree Display the project's dependency tree
tool Run and install commands provided by Python packages
python Manage Python versions and installations
pip Manage Python packages with a pip-compatible interface
venv Create a virtual environment
build Build Python packages into source distributions and wheels
cache Manage uv's cache
version Display uv's version
help Display documentation for a command
```
## Summary
Closes https://github.com/astral-sh/uv/issues/5610
This PR introduces additional images with the uv/uvx binaries from
scratch for both amd64/arm64 and make the mapping easy to configure by
generating the Dockerfile on the fly. This approach focuses on
minimizing CI time by taking advantage of dedicating a worker per
mapping (20-30s~ per job).
This PR also fixes `org.opencontainers.image.version` for all tags
(including the one from `scratch) to contain the right release version
instead of branch name `main` (default when no tag patterns are
specified).
For example, on release `x.y.z`, this will publish the following image
tags with format `ghcr.io/astral-sh/uv:{tag}` with manifests for both
amd64/arm64. This also include `x.y` tags for each respective additional
tag.
* From **scratch**: `latest`, `x.y.z`, `x.y` (currently being published)
* From **alpine:3.20**: `alpine`, `alpine3.20`, `x.y.z-alpine`,
`x.y.z-alpine3.20`
* From **debian:bookworm-slim**: `debian-slim`, `bookworm-slim`,
`x.y.z-debian-slim`, `x.y.z-bookworm-slim`
* From **buildpack-deps:bookworm**: `debian`, `bookworm`,
`x.y.z-debian`, `x.y.z-bookworm`
* From **python:3.12-alpine**: `python3.12-alpine`,
`x.y.z-python3.12-alpine`
* From **python:3.11-alpine**: `python3.11-alpine`,
`x.y.z-python3.11-alpine`
* From **python:3.10-alpine**: `python3.10-alpine`,
`x.y.z-python3.10-alpine`
* From **python:3.9-alpine**: `python3.9-alpine`,
`x.y.z-python3.9-alpine`
* From **python:3.8-alpine**: `python3.8-alpine`,
`x.y.z-python3.8-alpine`
* From **python:3.12-bookworm**: `python3.12-bookworm`,
`x.y.z-python3.12-bookworm`
* From **python:3.11-bookworm**: `python3.11-bookworm`,
`x.y.z-python3.11-bookworm`
* From **python:3.10-bookworm**: `python3.10-bookworm`,
`x.y.z-python3.10-bookworm`
* From **python:3.9-bookworm**: `python3.9-bookworm`,
`x.y.z-python3.9-bookworm`
* From **python:3.8-bookworm**: `python3.8-bookworm`,
`x.y.z-python3.8-bookworm`
* From **python:3.12-slim-bookworm**: `python3.12-slim-bookworm`,
`x.y.z-python3.12-slim-bookworm`
* From **python:3.11-slim-bookworm**: `python3.11-slim-bookworm`,
`x.y.z-python3.11-slim-bookworm`
* From **python:3.10-slim-bookworm**: `python3.10-slim-bookworm`,
`x.y.z-python3.10-slim-bookworm`
* From **python:3.9-slim-bookworm**: `python3.9-slim-bookworm`,
`x.y.z-python3.9-slim-bookworm`
* From **python:3.8-slim-bookworm**: `python3.8-slim-bookworm`,
`x.y.z-python3.8-slim-bookworm`
## Summary
Noticed that running `cargo dev generate-all` on `main` produced changes
and saw that that the command is not run on the CI nor as a pre-commit
hook.
Not sure if having the command running as a pre-commit hook is something
we want, so I can remove it if you prefer. I find that nice to have as
it's probably easy to forget to run it, especially for new contributors
(and it will only run if there are changes in `uv_cli` or `uv_settings`
crates).
## Test Plan
- Added `cargo dev generate-all --mode check` on the CI, which produced
[this failing
job](https://github.com/astral-sh/uv/actions/runs/10648055597/job/29516699393)
- Ran `cargo dev generate-all` locally and committed the changes, which
produced [this succeeding
job](https://github.com/astral-sh/uv/actions/runs/10648076910/job/29516744942)
As suggested by @samypr100 on #6680:
https://github.com/astral-sh/uv/pull/6680#issuecomment-2313607984
## Summary
Instead of using `UV_INTERNAL__TEST_DIR`, it simply exports `TEMP` when
running Windows jobs.
## Test Plan
I'm going to run this manually under ProcMon on my Windows machine and
see where uv writes temp files, hopefully to the dev drive and not
`%(LOCAL)APPDATA%` or something.
I'm going to commit a dummy code change and look at build time changes
in CI.
## Summary
Closes https://github.com/astral-sh/uv/issues/6678
This change would publish an additional tag that includes only
`major.minor`.
For a release with x.y.z, this would publish the tags:
* `ghcr.io/astral-sh/uv:latest`
* `ghcr.io/astral-sh/uv:x.y.z`
* `ghcr.io/astral-sh/uv:x.y`
## Summary
This PR makes `cargo test | windows` faster in CI.
### Before
### After
## Also
This PR disables the `brotli` feature of `async-compression` since it's
not strictly needed, but this has little to do with the improvements
(it's still less code to build).
This PR introduces additional code in uv tool uninstall to ignore errors
(that only seem to happen on ReFS, ie. on Dev Drives) akin to "the thing
we're trying to delete cannot be deleted because it's already being
deleted".
If `raw_os_error` was stable we could do u32 matching instead of that
`.to_string().contains()` abomination.
## Summary
This PR parallelizes multi-platform builds using multiple workers (hence
the new docker-build / docker-publish jobs), this seems to save about ~8
minutes.
This is partial work extracted from
https://github.com/astral-sh/uv/pull/6053 than is standalone
From 8 to 16 cores, 32 to 64 GB ram. Testing on Windows first because
it's the bottleneck.
Previously tested in #2515 to no effect, maybe better now that we have a
development drive?
## Summary
This is an experimental PR to replace more unsafe calls with more rust
while still trying to keep the binary size small enough. These changes
roughly increase the size of the trampolines to about 40kb~. This is a
alternate PR to https://github.com/astral-sh/uv/pull/5751.
The primary changes here include
* Switch to use rust path components for ease of path management
* Leverage `std::process::exit` for process exit and cleanup
* Use `std::io::Error::last_os_error` for IO Errors to remove
`FormatMessage` complexity
* Use `std::env::current_exe` to get the current executable instead of
`GetModuleFileNameA`
## Test Plan
Added one more existing test case to trampoline tests.
Still need to verify dunce::canonicalize is desired or not on
find_python_exe.
---------
Co-authored-by: konstin <konstin@mailbox.org>
To enforce the 100 character line limit in markdown files introduced in
https://github.com/astral-sh/uv/pull/5635, and to automate the
formatting of markdown files, i've added prettier and formatted our
markdown files with it.
I've excluded the changelog and the generated references documentation
from this for having too many changes, but we can also include them.
I'm not particular on which style we use. My main motivations are
(major) not having to reflow markdown files myself anymore and (minor)
consistence between all markdown files. I've chosen prettier for similar
reason as we chose black, it's a single good style that's automated and
shared in the community. I do prefer prettier's style of not breaking
inside of a link name though.
This PR is in two parts, the first adds prettier to CI and documents
using it, while the second actually formats the docs. When merge
conflicts arise, we can drop the last commit and regenerate it with `npx
prettier --prose-wrap always --write BENCHMARKS.md CONTRIBUTING.md
README.md STYLE.md docs/*.md docs/concepts/**/*.md docs/guides/**/*.md
docs/pip/**/*.md`.
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
Part of https://github.com/astral-sh/uv/issues/5713
Shaves 50s or ~25% off the Ubuntu test run. Maybe 30s or 8% off macOS.
Windows already uses the GitHub distributions.
Note this is some of our only test coverage for Python version installs,
we may want to add separate coverage to compensate.
## Summary
This PR deprecates the `--isolated` flag. The treatment varies across
the APIs:
- For non-preview APIs, we warn but treat it as equivalent to
`--no-config`.
- For preview APIs, we warn and ignore it, with two exceptions...
- For `tool run` and `run` specifically, we don't even warn, because we
can't differentiate the command-specific `--isolated` from the global
`--isolated`.
Add the tests added in #5204 to CI. The crate is not part of the
workspace (it requires nightly) and is windows only, so we have to test
it separately.
---------
Co-authored-by: samypr100 <3933065+samypr100@users.noreply.github.com>
## Summary
After #5337, `fetch-download-metadata.py` fetches not just from
`python-build-standalone`, so updates the workflow to
`sync-python-releases.yml`.
Also includes `crates/uv-python/download-metadata.json` in `add-paths`.
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
<!--
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
Currently, `uv` refuses to install anything on GraalPy. This is
currently blocking GraalPy testing with cibuildwheel, since manylinux
includes both `uv` and `graalpy` (but doesn't test with `uv`), whereas
cibuildwheel defaults to `uv`. See e.g.
https://github.com/pypa/cibuildwheel/actions/runs/9956369360/job/27506182952?pr=1538
where it gives
```
+ python -m build /project/sample_proj --wheel --outdir=/tmp/cibuildwheel/built_wheel --installer=uv
* Creating isolated environment: venv+uv...
* Using external uv from /usr/local/bin/uv
* Installing packages in isolated environment:
- setuptools >= 40.8.0
> /usr/local/bin/uv pip install "setuptools >= 40.8.0"
< error: Unknown implementation: `graalpy`
```
## Test Plan
I simply based the GraalPy support on PyPy and added some small tests.
I'm open to discussing how to test this. GraalPy is available for
manylinux images and with setup-python, so we should be able to add
tests against it to the CI. I locally confirmed by installing `uv` into
a GraalPy venv and then trying things like `uv pip install Pillow` and
testing those extensions.
renovate[bot]
Geoffrey Thomas
konsti
samypr100
Zanie Blue
Bryan Lee
Tim Felgentreff
Meitar Reihan
Charlie Marsh
Aria Desires
FishAlchemist
Martijn Pieters
Divyanshu Kalra
Jo
Mathieu Kniewallner
Hamir Mahal
sobolevn
Aarni Koskela
Bas Schoenmaeckers
bluss
Tom
Ibraheem Ahmed
Amos Wenger
Andrew Gallant
Tim Felgentreff