Separates Windows tests from the rest because it's a pain and drops the
`python-patch` feature from testing so we can use the GitHub Actions
Python versions which bootstrap in 0 seconds instead of 2 minutes.
## Summary
This PR adds system install tests to verify the behavior described in
#2798. It turns out this behavior _also_ affects Fedora and Amazon
Linux, we just didn't have the right conditions enabled (specifically,
you need to create the virtualenv with `python -m venv` to get these
symlinks), so the test suite was expanded to capture that.
The issue itself is also fixed by way of deduplicating the
`site-packages` entries.
Closes: https://github.com/astral-sh/uv/issues/2798
See https://github.com/astral-sh/uv/issues/2617
Note this also includes:
- #2918
- #2931 (pending)
A first step towards Python toolchain management in Rust.
First, we add a new crate to manage Python download metadata:
- Adds a new `uv-toolchain` crate
- Adds Rust structs for Python version download metadata
- Duplicates the script which downloads Python version metadata
- Adds a script to generate Rust code from the JSON metadata
- Adds a utility to download and extract the Python version
I explored some alternatives like a build script using things like
`serde` and `uneval` to automatically construct the code from our
structs but deemed it to heavy. Unlike Rye, I don't generate the Rust
directly from the web requests and have an intermediate JSON layer to
speed up iteration on the Rust types.
Next, we add add a `uv-dev` command `fetch-python` to download Python
versions per the bootstrapping script.
- Downloads a requested version or reads from `.python-versions`
- Extracts to `UV_BOOTSTRAP_DIR`
- Links executables for path extension
This command is not really intended to be user facing, but it's a good
PoC for the `uv-toolchain` API. Hash checking (via the sha256) isn't
implemented yet, we can do that in a follow-up.
Finally, we remove the `scripts/bootstrap` directory, update CI to use
the new command, and update the CONTRIBUTING docs.
<img width="1023" alt="Screenshot 2024-04-08 at 17 12 15"
src="https://github.com/astral-sh/uv/assets/2586601/57bd3cf1-7477-4bb8-a8e9-802a00d772cb">
Reproduced https://github.com/astral-sh/uv/issues/2941 and confirmed
fix.
We probably ought to have some ecosystem test coverage — this seems like
a good starting point we can extend to other projects in the future.
Following #2735 adds a system check that uses Homebrew. I think we were
never were actually using Homebrew's Python in the past, we were mislead
or something changed in the runners recently that broke it.
## Summary
Ensures that (e.g.) installs from conda-forge, Homebrew, and other
distributions don't expose `uv self update` at all.
We'll still show `uv self update` for `pip install uv`, but it will fail
with a good error. Removing the `uv self update` from `pip`-installed
`uv` is more complicated, since we'd need to build separately for the
installer vs. for PyPI.
Closes#2588.
Add a single job for for fast lint tools. Rustfmt for rust, ruff for
python formatting and linting, prettier avoids inconsistent formatter
changes between pycharm and vscode.
If you look at https://pypi.org/project/uv/0.1.22/#files...
- We didn't upload the ARMv6 wheel (I thought I had removed the `# Skip
for `arm`, which is not supported by PyPI.`), it must've gotten re-added
in a rebase or something.
- We lost the musllinux builds for ARM. I think this is because I built
them as manylinux.
Installing and importing numpy tests for two cases:
* The python architecture and the package architecture don't match
(https://github.com/astral-sh/uv/issues/2326)
* The libc of python and that of the package don't match on linux
(musllinux vs manylinux, picking a compatible manylinux version)
All pylint deps are py3-none-any, so they don't catch those cases.
Giving this a try... just making all of these a normal part of CI.
This is probably slightly slower than our normal CI, but not by much (it
depends how bad of a roll we get on the Windows network performance).
Includes #2309 to reduce the overhead of adding more platforms.
Alternatively, we could gate these with a label and just run on main by
default (i.e. #2308)
## Summary
Adjust maturing version to use env var for reusability in the workflow.
## Test Plan
CI `Build binaries` workflow uses correct version and passes
