## Summary
We now preserve source identity for transitive path dependencies
discovered while lowering metadata from Git-sourced packages. If a
dependency resolves to a directory inside the same Git checkout, we lock
it as the corresponding Git source with a `subdirectory` instead of
serializing the absolute checkout path.
Closes https://github.com/astral-sh/uv/issues/19152.
## Summary
`~=3.6` gets expanded to `>=3.6,<4.dev0`, which causes us to show a
pre-release hint. We now omit such ranges. This could lead to false
negatives (i.e., if a user _actually_ requested `>=3.6,<4.dev0`), but I
think this is the right tradeoff.
Closes https://github.com/astral-sh/uv/issues/19266.
uv pip uninstall `<pkg>` against a legacy` .egg-info` distribution with
an empty` top_level.txt` could resolve "" back to the distribution
location itself and end up deleting site-packages.
In `uninstall_egg` crate, each line from `top_level.txt `is now trimmed
and empty entries are skipped before iterating. Applied the same trim +
non-empty handling to `namespace_packages.txt` so both files are parsed
consistently. I did not also change is_path_in_scheme to reject paths
equal to a scheme root, since that is a broader defense-in-depth change
and outside the scope of this fix.
Covered by `test_uninstall_egg_info_empty_top_level` next to the
existing `test_uninstall_egg_info_path_traversal`, plus
`test_uninstall_egg_info_blank_lines_in_top_level` for blank and
whitespace-only lines between valid entries, which hits the same wipe
path before the fix. It fails on main with uninstall must not remove
site-packages itself and passes with this fix. Existing
`uninstall_egg_info`, `dry_run_uninstall_egg_info`, and
`uninstall_legacy_editable` integration tests still pass.
Closes#19113.
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
## Summary
We're using `url.path().starts_with(self.root_url.path())` and similar
logic in a few places, which treats `https://example.com/foobar` as a
subpath of `https://example.com/foo`, when these should really be at
path boundaries.
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [webpki](https://redirect.github.com/rustls/webpki) |
workspace.dependencies | patch | `0.103.12` → `0.103.13` |
---
### Configuration
📅 **Schedule**: (UTC)
- Branch creation
- Between 12:00 AM and 03:59 AM, only on Monday (`* 0-3 * * 1`)
- Automerge
- At any time (no schedule defined)
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/astral-sh/uv).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My4xNTkuMiIsInVwZGF0ZWRJblZlciI6IjQzLjE1OS4yIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJidWlsZDpza2lwLWRvY2tlciIsImJ1aWxkOnNraXAtcmVsZWFzZSIsImludGVybmFsIl19-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
CI is failing because https://pypi.org/project/lightning/ is
transitively included in some torch tests.
While we use exclude-newer for determinism, a project-level quarantine
means PyPI excludes all distributions from the responses.
## Summary
This is a small nice-to-have: previously to use `review` you'd need to
pass the run ID manually, since `apply-ci-snapshots.sh review` would
result in "review" being interpreted as the run ID.
## Test Plan
Dev only.
Signed-off-by: William Woodruff <william@astral.sh>
## Summary
Part of #18506. Closes#15254.
With this, we take the PEP 792 project status information (already
present in our internal representations per #15254) and use it to
produce appropriate adverse status reports (e.g. `hackme is
quarantined`).
To do this we need to make (frequently cached) registry client requests,
on top of whatever requests (currently just OSV) that `uv audit` needs
to make for known vulnerabilities/malware.
## Test Plan
I've added unit and integration tests, along with some `pypi-proxy`
scaffolding changes to allow us to easily test different project
statuses.
---------
Signed-off-by: William Woodruff <william@astral.sh>
`PYTHONHOME` isn't automatically cleaned up, so setting it causes it to
leak to child processes of Python, e.g., other, unrelated (perhaps not
even uv-controlled) Python builds, which breaks them. Never setting it
fixes#19080.
However, on the implementation of getpath on Python 3.10 and below,
leaving `PYTHONHOME` unset and pointing `__PYVENV_LAUNCHER__` at
something that isn't a venv or a directly-usable Python installation
(for example, pointing it to .local\bin\python3.10.exe) causes Python
startup to fail. So we only should be setting it inside a venv, i.e., if
the trampoline itself (not the target executable) is in a venv.
Presumably this failure on 3.10 is why we started setting PYTHONHOME in
the first place. See brief discussion in
https://github.com/astral-sh/uv/pull/13531/files#diff-969979506be03e89476feade2edebb4689a9c261f325988d3c7efc5e51de26d1
The putative benefit of setting `__PYVENV_LAUNCHER__` is to force
Python's idea of its own path to be the non-resolved junction path (e.g.
uv\python\cpython-3.10-..., not uv\python\cpython-3.10.0-...), to help
transparent version upgrades. If we don't manually set it to the
non-resolved path, there's a risk that Windows will resolve it. However,
empirically on Server 2022, Windows does not resolve it. (Also, even if
it does get canonicalized, that has a very limited impact on transparent
version upgrades, as venvs still list the junction path in pyvenv.cfg
and inside the trampoline. The only impact here is that sys.path etc.
might end up listing patch-version-specific paths, which would impact
some cases where code serializes the full path to something in the
stdlib or to sys._base_executable and calls it later. Also, Linux builds
of python-build-standalone have been fully canonicalizing this path
since December when we patched getpath to look at /proc/self/exe. That
new behavior is arguably a bug but this hasn't seemed to cause any
practical issues, so it doesn't seem like a real problem to risk Windows
perhaps doing the same thing.)
Unrelatedly, while we're rebuilding trampolines anyway, link with
/DEBUG:NONE to avoid storing the debug directory in the PE file, which
should slightly (but not entirely) reduce the amount of binary churn.
## Test Plan
Will need to be manually tested, I don't think we have good coverage for
this.
## Summary
This introduces a new workspace member, `uv-fastid`. `uv-fastid`
provides IDs using the same alphabet as nanoid, but with a slightly
smaller token size (16 instead of 21) and fewer knobs for configuration.
In practice it should also be faster, since our IDs are now trivially
copyable + don't require any heap allocations to construct internally.
This is probably not a huge deal in our case anyways (ID generation
isn't exactly dominating our runtime), but it doesn't hurt to have a
fast primitive here.
The two main APIs I've added are `insecure()` and `secure()`, whose
names refer to the kind of PRNG they use internally. Right now we only
use `insecure()`, since we don't actually need a CSPRNG for the uses of
nanoid we're replacing (revision and archive IDs).
Some other notes:
- Arguably we could remove the secure/insecure distinction entirely, and
just keep the CSPRNG path -- with `rand` we have a purely userspace
CSPRNG (seeded from the OS's CSPRNG), so we don't really need `fastrand`
for performance here.
- I'm guilty of using `unsafe` in this, although I think the usage is
demonstrably safe (as long as crate-private invariants are maintained) 🙂
- I think there's no breakage risk with this -- FWICT our only usage of
`nanoid` doesn't make any format assumptions, so switching to a slightly
shorter ID form here shouldn't break anything. Our previous IDs also
aren't part of any public interface AFAICT.
Closes https://github.com/astral-sh/uv/pull/19176.
## Test Plan
Added unit tests to the new `uv-fastid` crate. Our existing tests should
cover this transitively as well.
---------
Signed-off-by: William Woodruff <william@astral.sh>
See https://github.com/astral-sh/ruff/issues/24880, mimalloc v3 causes a
crash in uv too when run under aarch64 windows.
This PR bumps the crate dependency, adding the `v2` feature to avoid the
crash.
The uv build backend itself doesn't know if any particular previous
breaking release contained breaking changes for it, so we need to
manually update the list. This is easy to forget.
To prevent anyone from missing to update this list, we check for
something that looks like a missed release. If it was missed, it will
fail test (at latest in CI) on the breaking version change PR. This is
meant as oversight prevention, not as a release gate, if it fails
inappropriately just remove it.
github-actions[bot]