## Summary
- replace the current `FLASH_ATTENTION_SKIP_CUDA_BUILD` wording with a
more accurate description
- explain that the variable disables local CUDA compilation instead of
guaranteeing a compatible wheel
- recommend pinning to a known-supported combination when relying on
published wheels
Addresses #17794.
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
The following user-facing changes are included here:
- `aws-lc` is used instead of `ring` for a cryptography backend
- Expands our certificate signature algorithm support to include
ECDSA_P256_SHA512, ECDSA_P384_SHA512, ECDSA_P521_SHA256,
ECDSA_P521_SHA384, and ECDSA_P521_SHA512
- `--native-tls` is deprecated in favor of a new `--system-certs` flag,
avoiding confusion with the TLS implementation used (we use `rustls` not
`native-tls`, see prior confusion at
https://github.com/astral-sh/uv/issues/11595)
- NASM is a new build requirement on Windows, it is required by `aws-lc`
on x86-64 and i386
- `rustls-platform-verifier` is used instead of `rustls-native-certs`
for system certificate verification
- On macOS, certificate validation is now delegated to
`Security.framework` (`SecTrust`). Performance when using
`--system-certs` is improved by avoiding exporting and parsing all the
certificates from the keychain at startup.
- On Windows, certificate validation is now delegated to
`CertGetCertificateChain` and `CertVerifyCertificateChainPolicy`
- On Linux, certificate validation should be approximately unchanged
- Some previously failing chains may succeed, and some previously
accepted chains may fail; generally, this should result in behavior
closer matching browsers and other native applications
- macOS and Windows may now perform live OCSP fetches for early
revocation, which could add latency to some requests
- Empty `SSL_CERT_FILE` values are ignored (for consistency with
`SSL_CERT_DIR`)
The following internal changes are included here:
- Certificate loading has been refactored to use a newtype with helper
methods
- The certificate tests have been rewritten
- We use `webpki-root-certs` instead of `webpki-roots`, see
https://github.com/astral-sh/uv/pull/17543#discussion_r2820187691
- We request `identity` encoding for range requests, see
https://github.com/astral-sh/async_http_range_reader/pull/3#discussion_r2700194798
- Various dependencies (including forks) updates to versions which use
reqwest 0.13+
This is a replacement of #17543 with an updated description. See that
pull request for prior discussion. I've made the following changes from
the initial approach there:
- Previously, the `native-tls` TLS implementation was added which
included an OpenSSL build. We don't currently use the `native-tls`
implementation, but the `--native-tls` flag there was erroneously
updated to enable it.
- Previously, there was a `--tls-backend` flag to toggle between
`native-tls` and `rustls`. Since we currently always use `rustls`, this
is deferred to future work (if we need it at all).
- Previously, there were unintentional breaking changes to
`SSL_CERT_FILE` and `SSL_CERT_DIR` handling, including merging with the
base certificates instead of replacing them, dropping support for
OpenSSL hash-named certificate files, skipping deduplication of
certificates. Here, we retain use of `rustls-native-certs` for loading
certificates from the system as it handles these edge cases.
Closes https://github.com/astral-sh/uv/issues/17427
---------
Co-authored-by: salmonsd <22984014+salmonsd@users.noreply.github.com>
<!--
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
<!-- What's the purpose of the change? What does it do, and why? -->
The current documentation for virtual dependencies is somewhat confusing
because it places the sentence
> "the package will be built even if a build system is not declared"
immediately after introducing `tool.uv.package = false`. This makes it
sound as if the package might still be built when `package = false` is
set.
In reality, that sentence describes the *default behavior of path
dependencies* (when `package = false` is not set). The revised wording
clarifies that:
- `package = false` → the dependency becomes virtual (its dependencies
are installed, but the package itself is not built or installed)
- otherwise → uv treats the path dependency as a normal package and will
attempt to build it, even without a `[build-system]`.
<!--
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
<!-- What's the purpose of the change? What does it do, and why? -->
Suggest `uv python update-shell` over `uv tool update-shell` since we
are in the `uv python` area here.
## Test Plan
<!-- How was it tested? -->
n/a
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
It seems that PyPy is not being actively developed anymore and is phased
out even by numpy (https://github.com/numpy/numpy/issues/30416). There's
no official statement from the project, but the numpy issue is from a
PyPy developer. I added a warning to avoid users assuming PyPy properly
supported and developed Python distribution, and in anticipation of PyPy
being eventually, slowly deprecated.
---------
Co-authored-by: Tomasz Kramkowski <tom@astral.sh>
Resolves https://github.com/astral-sh/uv/issues/16846,
https://github.com/astral-sh/uv/issues/16813
This diff adds support for disabling `exclude-newer` for specific
packages using `<name>=false`. This allows packages
without upload dates (e.g., CPU-only PyTorch wheels from custom indices)
to be resolved when a global `exclude-newer` is set, without disabling
it globally.
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
Adds support for "friendly" durations like, 1 week, 7 days, 24 hours
using Jiff's parser. During resolution, we calculate this relative to
the current time and resolve it into a concrete timestamp for the
lockfile. If the span has not changed, e.g., to another relative value,
then locking again will not change the lockfile. The locked timestamp
will only be updated when the lockfile is invalidated, e.g., with
`--upgrade`. This prevents the lockfile from repeatedly churning when a
relative value is used.
Zanie Blue