uv 0.10 can use direct builds for uv_build with `<0.10`, there were no
breaking changes.
This PR also revamps the direct build detection to be more sensitive and
improves the errors messages.
---------
Co-authored-by: Aria Desires <aria.desires@gmail.com>
Includes a few things...
- Drops preview warnings for use of `uv python upgrade` and `uv python
install --upgrade`
- Adds `--resolve-links` to `uv python find`, which I needed in test
cases to retain existing snapshots
- Fixes issues in our "Using environment ..." messages on Windows which
were incorrect
- Refactors `from_executable` for the `PythonMinorVersionLink` type
(https://github.com/astral-sh/uv/pull/17842/commits/28b2ed2525327d94fdf5372a29bbbc476d74680f)
to use the type system to prevent incorrect construction (for above)
- Removes special casing where we only upgrade links if they already
exist, which existed so preview wasn't needed on every invocation
- Fixes a bug with `PythonMinorVersionLink::exists` which returned
`true` even if the link pointed to the wrong Python installation leading
to discovery failures
I needed this for a test, e.g., to disable a source for an extra build
dependency without disabling the source for a workspace member, and had
also seen some requests for it. I think it makes sense to allow this.
The refactor is fairly mechanical, we go from
`SourceStrategy::Enabled|Disabled` to
`NoSources::All|None|Package(names)` as we do for other options like
`NoBinary`.
Related https://github.com/astral-sh/uv/issues/17441
https://discuss.python.org/t/pep-819-json-package-metadata/105558
Add an experimental JSON format for METADATA and WHEEL files in the uv
build backend to have a reference what it would look like and to
demonstrate that the actual change is just a few lines, how much easier
it is than the existing email header format.
The change is overwhelmingly adding the preview feature as it's the
first preview item in the build backend, writing the actual JSON is only
a couple of lines.
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
Fixes https://github.com/astral-sh/uv/issues/16447
Passing this around explicitly uncovers some behaviors where we pass
e.g. the credentials store to reading the lockfile. The changes in this
PR should preserve the existing behavior for now, they only make the
locations we read from more explicit.
Labeling this PR as "Enhancement" instead of "Internal" in case this
changes behavior when it shouldn't have.
## Summary
Fix#16906 by pruning modules or submodules which are already included
(either directly, or through a parent).
Generates warnings when this happens.
Example:
```bash session
$ uv build
Building source distribution (uv build backend)...
warning: Ignoring redundant module name(s): test_lib.bar test_lib test_lib.bar.baz test_lib.baz
Building wheel from source distribution (uv build backend)...
Successfully built dist/test-0.1.0.tar.gz
Successfully built dist/test-0.1.0-py3-none-any.whl
```
## Test Plan
Added some unit tests for the pruning function and one for the whole
build backend. Added an integration test for the warnings. Ran the full
test suite. Manually tested.
The unit test for the function doesn't cater for the fact that it
doesn't guarantee an order at the moment. I think this is fine.
---------
Co-authored-by: konsti <konstin@mailbox.org>
Part of https://github.com/astral-sh/uv/issues/4392
We shouldn't link to PyPI, and dropping the workspace-level
documentation link should mean that we get the auto-generated `docs.rs`
links.
## Summary
Fixes issue #15190 where `uv sync --no-sources` fails to switch from
editable to registry package installations. The problem occurred because
the installer's satisfaction check didn't consider the `--no-sources`
flag when determining if an existing editable installation was
compatible with a registry requirement.
## Solution
Modified `RequirementSatisfaction::check()` to reject non-registry
installations when `SourceStrategy::Disabled` and the requirement is
from registry. Added `SourceStrategy` parameter threading through the
entire call chain from commands to the satisfaction check to ensure
consistent behavior between `uv sync --no-sources` and `uv pip install
--no-sources`.
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
## Summary
This is causing some cyclic dependencies issues for me, because these
can be used in virtually _any_ crate (like `uv-install-wheel`), which
then means that all of `uv-configuration` becomes a dependency, etc. I
think this should be a leaf crate so that we can safely depend on it
anywhere.
## Summary
This PR productionizes an idea I saw in
https://github.com/astral-sh/uv/issues/15248, which was added in Pixi:
https://github.com/prefix-dev/pixi/pull/4247. The core of the idea is
that if we install all build isolation-enabled packages first, and the
build isolation-disabled packages in a second phase, the sync is more
likely to "just work", because if all the build dependencies of the
build isolation-disabled packages are included as dependencies (as is
the case for `flash-attn`, at least), they'll be present.
This isn't really a silver bullet, because it requires that all the
build dependencies are included as first-party dependencies, and if you
have packages that want build isolation to be disabled but rely on other
packages that also require build isolation disabled, that won't work
either. I think `extra-build-dependencies` will be more robust and have
much better caching behavior, but this will get more cases right than
our current behavior, and I don't see any downsides.
Closes https://github.com/astral-sh/uv/issues/15301.
## Summary
If `match-runtime = true`, but we can't resolve a package's metadata
statically, then we can't _know_ what the runtime version of the package
will be -- because we can't resolve without building it. This PR makes
that footgun clearer by raising an error.
Closes https://github.com/astral-sh/uv/issues/15264.
## Summary
This breaks up a cycle I'm running into in incorporating the build
configuration into our cache keys. This is actually a type that ends up
in the frontend build system, etc., so I think it makes more sense here
anyway (as opposed to `uv-configuration` which tend to be our own
user-facing types).
## Summary
Make the use of `Self` consistent. Mostly done by running `cargo clippy
--fix -- -A clippy::all -W clippy::use_self`.
## Test Plan
<!-- How was it tested? -->
No need.
Zanie Blue