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>