## Summary
Lockfile re-validation was iterating from the workspace roots; but for
scripts, we have no roots! This is similar to the approach we use in `uv
tree`, `uv export`, etc.
Closes https://github.com/astral-sh/uv/issues/18312.
The difference is below the noise threshold, but it showed up in the
profiled. The code originally existed for error handling that has since
been removed.
<!--
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
torchcodec added
https://github.com/astral-sh/uv/issues/18335
<!-- What's the purpose of the change? What does it do, and why? -->
## Test Plan
<!-- How was it tested? -->
## Summary
Handle the case where too many hardlinks were created and thus
installing packages fails.
There are cases where the file system can have a hardlinks limit and
when it's hit `uv` fails,
for example AWS EFS that has a limit of 177 hard links (
https://docs.aws.amazon.com/efs/latest/ug/troubleshooting-efs-fileop-errors.html#hardlinkerror
)
This PR address this by resetting the hardlinks when the limit is
reached (it does this by replacing the file in the cache, so new
hardlinks can be made)
There can be race conditions over the limit, but those are ok, as the
links are reset atomically so in case of race conditions the worst case
will be that the limit is reset twice, but nothing will break.
## Test Plan
Add a `install_hardlink_after_emlink` function, it successfully
reproduced the issue on my system.
The issue is that it's expensive to run as it has to generate a lot of
hardlinks
---------
Co-authored-by: Tomasz Kramkowski <tom@astral.sh>
In a warm cache situation, e.g. with `uv run`, toml parsing is by far
our slowest operation. These kinda hacky spans help debugging that. It
would be better if `toml::from_str` would be instrumented itself, but
this way we can add paths in the relevant places.
To help with cases such as https://github.com/astral-sh/uv/issues/15655.
A question is when to show this warning. I've used sources as a proxy as
URL dependencies with enabled sources are likely those controlled by the
user, and they include workspace and `git clone`d path dependencies.
The first commit is a refactoring, the second commit the implementation.
Fixes https://github.com/astral-sh/uv/issues/15740
## Summary
Replace `remove_dir_all` with `remove_virtualenv` for the tool environment creation code path.
Closes#14985
## Test Plan
Relied on existing test coverage.
---------
Co-authored-by: Tomasz Kramkowski <tomasz@kramkow.ski>
Add `with_filtered_latest_python_versions()` to tests that were using
hardcoded patch versions for latest Python releases. This makes the
tests resilient to Python version bumps by using `[LATEST]` placeholders
instead of specific version numbers like `3.12.12` or `3.10.19`.
Also use `LATEST_PYTHON_3_12` constant for constructing directory paths
in the build version upgrade tests.
<!--
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
will close https://github.com/astral-sh/uv/issues/17160
Basically, old code using nodes with no incoming edges included
transitive deps which resulted in orphaned roots. We didnt actually need
that code as well, infinite cycle handling was done in `fn visit`
correctly so just using root node directly solves the issue. I also
found another bug during the process where packages were marked as
"visited" prematurely resulting in not even expanding them and not
showing them at the tree.
## Test Plan
I added two tests with snapshots.
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
## Summary
<!-- What's the purpose of the change? What does it do, and why? -->
Fixes#18021
Store dependencies excluded by uv tool install in the tool receipt and
provide these same dependencies to the requirements resolver when the
tool is upgraded.
## Test Plan
<!-- How was it tested? -->
Running the repro commands provided in issue #18021, we can see the
excluded dependency does not get reinstalled when the tool is upgraded:
```sh
$ cat /tmp/excludes.txt
markdown-it-py
$ ~/Dev/uv/target/debug/uv install --excludes /tmp/excludes.txt 2048-cli==1.0.2
Resolved 7 packages in 150ms
Installed 7 packages in 56ms
+ 2048-cli==1.0.2
+ click==8.3.1
+ maturin==1.12.0
+ numpy==2.4.2
+ pygments==2.19.2
+ rich==13.9.4
+ rich-menu==0.3.0
Installed 1 executable: 2048-cli
$ cat ~/.local/share/uv/tools/2048-cli/uv-receipt.toml
[tool]
requirements = [{ name = "2048-cli" }]
excludes = ["markdown-it-py"]
entrypoints = [
{ name = "2048-cli", install-path = "/home/brad/.local/bin/2048-cli", from = "2048-cli" },
]
$ ~/Dev/uv/target/debug/uv tool upgrade 2048-cli
Updated 2048-cli v1.0.2 -> v1.0.3
- 2048-cli==1.0.2
+ 2048-cli==1.0.3
Installed 1 executable: 2048-cli
```
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
## Summary
This provides the scaffolding (CLI and initial `uv-audit` crate) for a
`uv audit` subcommand.
Closes#9189.
Tracking:
- [x] Core CLI scaffolding (this PR)
- [x] #18185
- [x] Audit core (probably a new `uv-audit` crate): #18124
- [ ] Bulk dependency audits with OSV
- [ ] Result presentation
- [ ] #18193
Things that also need to be done with the MVP:
- [ ] We should not audit workspace members by default (by definition,
they don't exist on indices and therefore don't have meaningful results
from vulnerability services).
- [ ] I need to ensure groups/etc. are being filtered by correctly,
right now we audit every single package in the lockfile unconditionally.
## Test Plan
Unit and integration tests commensurate with the new functionality.
---------
Signed-off-by: William Woodruff <william@astral.sh>
## Summary
If the user provides credentials for an index URL during tool install,
we strip the credentials. However, we now store the authentication
policy as `always` to ensure that if the user attempts to upgrade, and
we can't query the index, we correctly fail.
This won't cover credentials provided via keyring, but it will cover
embedded credentials and environment variables.
Closes https://github.com/astral-sh/uv/issues/18120.
## Summary
[`pip-compile`] (jazzband) has the following semantics when invoked with
both `--upgrade` and `--upgrade-package={pkg}{constraint}`: upgrade all
packages WHILE abiding by the constraints provided.
Currently, `uv` ignores the additional constraints, merging `--upgrade`
and `--upgrade-package` simply as `--upgrade`, which is obviously a
divergence in behavior. This leads to specific package constraints being
ignored, even when explicitly provided. When I went to look at patching
this, I noticed an open TODO around the same behavior in the
`--no-upgrade` case.
As a solution, separate the `UpgradeStrategy` from the constraints
provided, allowing for a more graceful merge.
[`pip-compile`]: https://github.com/jazzband/pip-tools
I've created an issue to track this here:
https://github.com/astral-sh/uv/issues/18225
## Test Plan
I've added a few integration tests to cover this case (including
updating the negative test that existed), and updated the relevant
snapshots.
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
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>
Avoid churn in this file when IDEs remove the trailing whitespace while
the snapshot contains. This single space looks like a typo in the pyenv
placeholder package.
Alternative to https://github.com/astral-sh/uv/pull/18182.
By default, retry-policies compute the actual retry duration as
`min_retry_interval * (base ** n_past_retries) * rng.uniform(0.0, 1.0)`,
so the first sleep duration would be between 0s and 1s. This change
bumps this to a real 1s minimum.
## Summary
If no revision is specified, we should assume the input used the default
branch (rather than returning early and ignoring the existing SHA).
Closes https://github.com/astral-sh/uv/issues/18224.
Resolves https://github.com/astral-sh/uv/issues/18202
This diff adds a `UV_INIT_BARE` environment variable that makes `--bare`
the default behavior for `uv init`. The command-line flag takes
precedence over the environment variable, following the same pattern
used by `UV_FROZEN`, `UV_LOCKED`, and other boolean environment
variables.
<!--
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
If a package uses meson-python as backend, it's declared as:
```
[build-system]
build-backend = 'mesonpy'
requires = ['meson-python']
```
Currently, if meson-python is missing, one gets the following hint:
```
Traceback (most recent call last):
File "<string>", line 8, in <module>
import mesonpy as backend
ModuleNotFoundError: No module named 'mesonpy'
hint: This error likely indicates that `sagemath` depends on `mesonpy`, but doesn't declare it as a build
dependency. If `sagemath` is a first-party package, consider adding `mesonpy` to its `build-system.requires`.
Otherwise, either add it to your `pyproject.toml` under:
[tool.uv.extra-build-dependencies]
sagemath = ["mesonpy"]
or `uv pip install mesonpy` into the environment and re-run with `--no-build-isolation`.
```
which is not quite correct as the build backend/module is called
"mesonpy" but the python package one has to install is "meson-python".
This hint is improved in this PR.
<!-- What's the purpose of the change? What does it do, and why? -->
## Test Plan
I didn't yet had a chance to setup a local dev env for testing this.
<!-- How was it tested? -->
Resolves#18014 (also related to
https://github.com/astral-sh/uv/issues/18010)
When `--exclude-newer` is active and all versions of a required package
were uploaded after the cutoff, resolution fails with no indication that
the setting is the cause. This diff adds a resolver hint that surfaces
the relationship.
The diff also includes debug-level logging of the exclude-newer
configuration at resolver start (happy to get this in separately, if
needed), and trace-level logging each time an individual file is
excluded by the timestamp cutoff. These help diagnose resolution
behavior without requiring the hint to fire.
Charlie Marsh