5872 commits

This branch

This branch

All branches

Author	SHA1	Message	Date
Zanie Blue	6d3614eece	Bump version to 0.6.2 (#11630)	2025-02-19 13:11:11 -06:00
Zanie Blue	326d0c460a	Add emulated test for x86-64 Python on aarch64 Windows (#11626) ... Coverage of https://github.com/astral-sh/uv/pull/11625 for unmanaged Python.	2025-02-19 12:02:13 -06:00
Zanie Blue	fdebc0c7fd	Allow use of x86-64 Python on ARM Windows (#11625) ... Closes https://github.com/astral-sh/uv/issues/11493	2025-02-19 12:01:46 -06:00
konsti	80b0d4c4e2	Revert: Include environment variables in interpreter info caching (#11622) ... Revert #11601 for now We run Python interpreter discovery with `-I` (#2500) which means these environments variables are ignored when determining `sys.path`. Unless we decide to remove the `-I` flag from the `sys.path` query, we shouldn't release these changes to interpreter discovery caching.	2025-02-19 10:10:21 -06:00
Jo	c57fb4dcef	Make fetching github releases faster (#11614) ... I noticed that the latest two `sync-python-releases` jobs failed due to `httpx.RemoteProtocolError: peer closed connection without sending complete message body (incomplete chunked read)`. For the current python-build-standalone release, each request page (defaulting to 30 items per page) takes about 20 seconds and loads around 32MB of data. This extensive data load might be causing the request to frequently fail. In this PR, I reduced number of items per page to 10 and added `Accept-Encoding: gzip, deflate` to the request header. Now, it takes about 6 seconds to load, and the compressed response size has been reduced to 534KB. I hope this would addresses the request failure.	2025-02-19 08:57:56 -06:00
konsti	e8712800d1	Regenerate env var docs (#11616) ... Follow-up for https://github.com/astral-sh/uv/pull/11601	2025-02-19 11:31:17 +01:00
konsti	da30cc4ec5	Include environment variables in interpreter info caching (#11601) ... We want to use `sys.path` for package discovery (#2500, #9849). For that, we need to know the correct value of `sys.path`. `sys.path` is a runtime-changeable value, which gets influenced from a lot of different sources: Environment variables, CLI arguments, `.pth` files with scripting, `sys.path.append()` at runtime, a distributor patching Python, etc. We cannot capture them all accurately, especially since it's possible to change `sys.path` mid-execution. Instead, we do a best effort attempt at matching the user's expectation. The assumption is that package installation generally happens in venv site-packages, system/user site-packages (including pypy shipping packages with std), and `PYTHONPATH`. Specifically, we reuse `PYTHONPATH` as dedicated way for users to tell uv to include specific directories in package discovery. A common way to influence `sys.path` that is not using venvs is setting `PYTHONPATH`. To support this we're capturing `PYTHONPATH` as part of the cache invalidation, i.e. we refresh the interpreter metadata if it changed. For completeness, we're also capturing other environment variables documented as influencing `sys.path` or other fields in the interpreter info. This PR does not include reading registry values for `sys.path` additions on Windows as documented in https://docs.python.org/3.11/using/windows.html#finding-modules. It notably also does not include parsing of python CLI arguments, we only consider their environment variable versions for package installation and listing. We could try parsing CLI flags in `uv run python`, but we'd still miss them when Python is launched indirectly through a script, and it's more consistent to only consider uv's own arguments and environment variables, similar to uv's behavior in other places.	2025-02-19 10:10:19 +00:00
Aria Desires	f394f72453	respect color settings for log messages (#11604) ... fixes #11560	2025-02-18 15:39:28 -05:00
Zanie Blue	0d29382664	Move clone_recursive documentation (#11579) ... While investigating #11554 I noticed this was not quite correct and hard to find.	2025-02-18 13:31:37 -06:00
John Mumm	b086437bff	Sort dependency group keys when adding new group (#11591) ... This change keeps dependency group keys sorted when adding new ones. If earlier dependency group keys were not sorted, we just append the new group key to avoid churn in `pyproject.toml`. See discussion on #11447. I've added a new snapshot test to capture this case. Closes #11447.	2025-02-18 19:12:50 +01:00
FishAlchemist	555bf89b38	Add document for specifying Python interpreter in tool installation and upgrade commands. (#11598) ... <!-- 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 Just to add the section for installing and upgrading uv tool, specifying the Python version, in the document. Originally, it was planned to add a markdown block (header) for representation, but it was felt to be a bit redundant, so it ended up being like this. close https://github.com/astral-sh/uv/issues/11536 ## Test Plan Run doc server with strict mode in local. (``mkdocs serve -f mkdocs.public.yml --strict``)  <!-- How was it tested? --> --------- Signed-off-by: FishAlchemist <48265002+FishAlchemist@users.noreply.github.com> Co-authored-by: Zanie Blue <contact@zanie.dev>	2025-02-18 11:45:58 -06:00
konsti	3634a4d8e9	More consistent build-binaries.yml (#11478) ... 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>	2025-02-18 11:36:26 -06:00
Michał Górny	aca7be8378	Set COLUMNS in Linux CI workflow to prevent regressions (#11589) ... ## Summary When tests are run downstream, the `COLUMNS` environment variable is used to force fixed output width and avoid test failures due to different terminal widths. However, this occasionally causes test regressions when other tests rely on different output width. Use the same `COLUMNS` value in CI to ensure consistent output and catch any regressions. ## Test Plan It wasn't, it's supposed to be tested by the CI :-). --------- Co-authored-by: Zanie Blue <contact@zanie.dev>	2025-02-18 16:38:28 +00:00
Andrew Gallant	c3fc75d97e	uv/tests: update snapshots for bad merge (#11597) ... The bad merge was a result of merging #11293 and #11513. I think even if I had only merged the former, it still would have resulted in a bad merge, since the snapshots hadn't been updated for `provide-extras` additions. This fixes the build failures seen here: 3739802963	2025-02-18 08:48:10 -05:00
Andrew Gallant	ed51d76caf	uv/tests: update snapshots to account for more conservative conflict marker simplification ... This is fallout from skipping simplification when two or more edges with the same package name exist.	2025-02-18 07:45:24 -05:00
Andrew Gallant	91593d42d9	uv-resolver: fix conflict marker simplification bug ... The particular example I honed in on here was the `e3nn -> sympy 1.13.1` and `e3nn -> sympy 1.13.3` dependency edges. In particular, while the former correctly has a conflict marker, the latter's conflict marker was getting simplified to `true`. This makes the edges trivially overlapping, and results in both of them getting installed simultaneously. (A similar problem happens for the `e3nn -> torch` dependency edges.) Why does this happen? Well, conflict marker simplification works by detecting which extras are known to be enabled (and disabled) for each node in the graph. This ends up being expressed as a set of sets, where each inner set contains items corresponding to "extras is included" or "extra is excluded." The logic then is if _all_ of these sets are satisfied by the conflict marker on the dependency edge, then this conflict marker can be simplified by assuming all of the inclusions/exclusions to be true. In this particular case, we run into an issue where the set of assumptions discovered for `e3nn` is: {test[sevennet]}, {}, {~test[m3gnet], ~test[alignn], test[all]} And the corresponding conflict marker for `e3nn -> sympy 1.13.1` is: extra == 'extra-4-test-all' or extra == 'extra-4-test-chgnet' or (extra != 'extra-4-test-alignn' and extra != 'extra-4-test-m3gnet') And the conflict marker for `e3nn -> sympy 1.13.3` is: extra == 'extra-4-test-alignn' or extra == 'extra-4-test-m3gnet' Evaluating each of the sets above for `sympy 1.13.1`'s conflict marker results in them all being true. Simplifying in turn results in the marker being true. For `sympy 1.13.3`, not all of the sets are satisfied, so this marker is not simplified. I think the fundamental problem here is that our inferences aren't quite rich enough to make these logical leaps. In particular, the conflict marker for `e3nn -> sympy 1.13.3` is not satisfied by _any_ of our sets. One might therefore conclude that this dependency edge is impossible. But! The `test[sevennet]` set doesn't actually rule out `test[m3gnet]` from being included, for example, because there is no conflict. So it is actually possible for this marker to evaluate to true. And I think this reveals the problem: for the `e3nn -> sympy 1.13.1` conflict marker, the inferences don't capture the fact that `test[sevennet]` _might_ have `test[m3gnet]` enabled, and that would in turn result in the conflict marker evaluating to `false`. This directly implies that our simplification here is inappropriate. It would be nice to revisit how we build our inferences here so that they are richer and enable us to make correct logical leaps. For now, we fix this particular bug with a bit of a cop-out: we skip conflict marker simplification when there are ambiguous dependency edges. Fixes #11479	2025-02-18 07:45:24 -05:00
Andrew Gallant	aaf3429e3f	uv/tests: add regression test for duplicate torch and sympy dependencies ... The place to look in this snapshot is the `name = "e3nn"` dependency. Its dependencies on `sympy` and `torch` consist of multiple versions with overlapping conflict markers. They are getting incorrectly simplified to `true`.	2025-02-18 07:45:24 -05:00
Andrew Gallant	2bda549bcc	uv-resolver: fix lock file instability with conflict markers ... This does the work to parse conflict markers back into a series of conflict inclusions and exclusions that can be used during resolution. Fixes #9735	2025-02-18 07:44:12 -05:00
Andrew Gallant	b48e6b9862	uv-pep508: add routine for visiting all extras in a marker tree ... We'll need this to be able to decode conflict markers back into a series of inclusion/exclusion rules used during resolution.	2025-02-18 07:44:12 -05:00
Andrew Gallant	1af31d0cc4	uv/tests: add lock file bloating regression test ... The second lock snapshot in particular demonstrates the problem: we have a bunch of `python_version < '0'` in the resolution markers. Ref #9735	2025-02-18 07:44:12 -05:00
konsti	929e7c3ad9	Revert "Temporarily disable cloudsmith test" (#11590) ... Cloudsmith increased our limit, we can test on cloudsmith again. This reverts commit f675c119dd.	2025-02-18 10:00:09 +01:00
Charlie Marsh	204f46fc83	Use an Arc for Index URLs (#11586) ... ## Summary I realized that we clone this for every distribution. It looks like it's consistently 1-2% faster to use an `Arc` here.	2025-02-18 02:22:36 +00:00
konsti	29c2be3e97	Eagerly reject unsupported Git schemes (#11514) ... Initially, we were limiting Git schemes to HTTPS and SSH as only supported schemes. We lost this validation in #3429. This incidentally allowed file schemes, which apparently work with Git out of the box. A caveat for this is that in tool.uv.sources, we parse the git field always as URL. This caused a problem with #11425: repo = { git = 'c:\path\to\repo', rev = "xxxxx" } was parsed as a URL where c: is the scheme, causing a bad error message down the line. This PR: * Puts Git URL validation back in place. It bans everything but HTTPS, SSH, and file URLs. This could be a breaking change, if users were using a git transport protocol were not aware of, even though never intentionally supported. * Allows file: URL in Git: This seems to be supported by Git and we were supporting it albeit unintentionally, so it's reasonable to continue to support it. * It does not allow relative paths in the git field in tool.uv.sources. Absolute file URLs are supported, whether we want relative file URLs for Git too should be discussed separately. Closes #3429: We reject the input with a proper error message, while hinting the user towards file:. If there's still desire for relative path support, we can keep it open. --------- Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>	2025-02-18 02:14:06 +00:00
Chao Ning	8c3a6b2155	Add tool.uv.build-constraint-dependencies to pyproject.toml (#11585) ... ## Summary Resolves #6913. Add `tool.uv.build-constraint-dependencies` to pyproject.toml. The changes are analogous to the constraint-dependencies feature implemented in #5248. Add documentation for `build-constraint-dependencies` ## Test Plan Add tests for `uv lock`, `uv add`, `uv pip install` and `uv pip compile`. --------- Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>	2025-02-17 20:58:36 -05:00
konsti	8996d5c358	Temporarily disable cloudsmith test (#11581) ... We've run into a ratelimit, disable the test until that's bumped.	2025-02-17 12:27:52 -06:00
Zanie Blue	c91ee82a82	Bump version to 0.6.1 (#11580)	2025-02-17 11:57:47 -06:00
Charlie Marsh	d8aaa17ccd	Add documentation for required environments (#11542) ... ## Summary Right now, there's documentation in the settings reference. This adds some standalone prose.	2025-02-17 11:27:57 -06:00
John Mumm	1bc7d93f4c	Fix macro typo (#11578) ... This typo wasn't caught because the `($arg:expr, false)` macro branch was never exercised. For example, prior to this change, if you add ``` show_settings!(globals, false); ``` below, you'll get a compiler error.	2025-02-17 16:57:51 +01:00
konsti	90e9287dd8	Warn for builds in non-build and workspace root pyproject.toml (#11394) ... When running `uv pip install .` in a directory with a pyproject.toml that does not configure a build, we will invoke setuptools and get a wheel we can't parse (https://github.com/astral-sh/uv/issues/11344). This PR adds warnings around these setups. --------- Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>	2025-02-17 15:57:18 +00:00
Jo	0498b9fb1d	Make fetch python downloads deterministic (#11572) ... Closes #11549	2025-02-17 08:36:38 -06:00
konsti	248da23f6d	Split uv-git and uv-git-types (#11448) ... We want to build `uv-build` without depending on the network crates. In preparation for that, we split uv-git into uv-git and uv-git-types, where only uv-git depends on reqwest, so that uv-build can use uv-git-types.	2025-02-17 10:37:55 +01:00
Charlie Marsh	e95da5c3af	Accept iterator in universal marker evaluation (#11571) ... ## Summary Something I noticed while working on https://github.com/astral-sh/uv/issues/11548.	2025-02-17 03:29:45 +00:00
renovate[bot]	e21f793a1f	Update Rust crate clap to v4.5.29 (#11564)	2025-02-16 22:04:13 -05:00
renovate[bot]	39b28b210c	Update Rust crate tempfile to v3.17.0 (#11570)	2025-02-16 21:49:47 -05:00
renovate[bot]	040ee26531	Update Rust crate smallvec to v1.14.0 (#11569)	2025-02-16 21:49:34 -05:00
renovate[bot]	fbed410c53	Update Rust crate jiff to 0.2.0 (#11568)	2025-02-16 21:49:21 -05:00
renovate[bot]	8c6792ebe0	Update Rust crate codspeed-criterion-compat to v2.8.0 (#11567)	2025-02-16 21:49:14 -05:00
renovate[bot]	93b363bbd6	Update pre-commit dependencies (#11566)	2025-02-16 21:49:10 -05:00
renovate[bot]	4a8fc5df91	Update Rust crate toml_edit to v0.22.24 (#11565)	2025-02-16 21:49:03 -05:00
Charlie Marsh	4e6c07665c	Remove clone from marker evaluation (#11562) ... ## Summary Something I noticed while looking at https://github.com/astral-sh/uv/issues/11548.	2025-02-16 20:55:27 +00:00
Zanie Blue	346e6b7e8b	Fallback to GET on HTTP 400 when attempting to use range requests for wheel download (#11539) ... See https://github.com/astral-sh/uv/issues/11501	2025-02-15 22:02:46 -06:00
Charlie Marsh	47fb59fdab	Prefer local variants in preference selection (#11546) ... ## Summary This PR fixes a subtle issue arising from our propagation of preferences. When we resolve a fork, we take the solution from that fork and mark all the chosen versions as "preferred" as we move on to the next fork. In this specific case, the resolver ended up solving a macOS-specific fork first, which led us to pick `2.6.0` rather than `2.6.0+cpu`. This in itself is correct; but when we moved on to the next fork, we preferred `2.6.0` over `2.6.0+cpu`, despite the fact that `2.6.0` _only_ includes macOS wheel, and that branch was focused on Linux. Now, in preferences, we prefer local variants (if they exist). If the local variant ends up not working, we'll presumedly backtrack to the base version anyway. Closes https://github.com/astral-sh/uv/issues/11406.	2025-02-15 20:35:47 -05:00
Charlie Marsh	08ad56e590	Remove redundant index from preference key (#11543) ... ## Summary We already filter by this on Line 201.	2025-02-15 18:58:56 -05:00
Charlie Marsh	985e5be96e	Add --all to uvx --reinstall message (#11535) ... ## Summary See: https://github.com/astral-sh/uv/issues/8067#issuecomment-2660898125	2025-02-15 14:03:53 +00:00
github-actions[bot]	15d75f91df	Sync latest Python releases (#11527) ... Automated update for Python releases. Co-authored-by: zanieb <2586601+zanieb@users.noreply.github.com>	2025-02-15 00:51:47 +00:00
Aria Desires	fbe9e33b8d	Note that main.py used to be hello.py (#11519) ... Co-authored-by: Zanie Blue <contact@zanie.dev>	2025-02-14 21:59:25 +00:00
Charlie Marsh	36b4fd2d2d	Respect verbatim executable name in uvx (#11524) ... ## Summary If the user provides a PEP 508 requirement (e.g., `uvx change_wheel_version`), then we should us that verbatim for the executable, rather than normalizing the package name. Closes https://github.com/astral-sh/uv/issues/11521.	2025-02-14 21:25:17 +00:00
Charlie Marsh	172305abb6	Allow users to mark platforms as "required" for wheel coverage (#10067) ... ## Summary This PR revives https://github.com/astral-sh/uv/pull/10017, which might be viable now that we _don't_ enforce any platforms by default. The basic idea here is that users can mark certain platforms as required (empty, by default). When resolving, we ensure that the specified platforms have wheel coverage, backtracking if not. For example, to require that we include a version of PyTorch that supports Intel macOS: ```toml [project] name = "project" version = "0.1.0" requires-python = ">=3.11" dependencies = ["torch>1.13"] [tool.uv] required-platforms = [ "sys_platform == 'darwin' and platform_machine == 'x86_64'" ] ``` Other than that, the forking is identical to past iterations of this PR. This would give users a way to resolve the tail of issues in #9711, but with manual opt-in to supporting specific platforms.	2025-02-14 15:11:18 -05:00
Zanie Blue	9cdfad191c	Add tiny change to changelog (#11517)	2025-02-14 19:31:32 +00:00
Zanie Blue	2bc6ca35e5	Split changelog into separate files (#11510) ... GitHub consistently crashes while rendering our existing `CHANGELOG.md` — we got a lot of changes! Here I add a new directory and split the changelog on our "breaking" versions. See https://github.com/astral-sh/uv/tree/zb/cl-split/changelogs and https://github.com/astral-sh/uv/blob/zb/cl-split/CHANGELOG.md#05x The downside is that we'll break some links. I don't think there's much to be done about it though.	2025-02-14 13:20:05 -06:00