## 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 😄)
