## Summary
`uv run --project ./path/to/project` now uses the provided directory as
the starting point for any file discovery. However, relative paths are
still resolved relative to the current working directory.
Closes https://github.com/astral-sh/uv/issues/5613.
## Summary
Originally wanted to update the reference to `astral-sh/setup-uv` in
https://docs.astral.sh/uv/guides/integration/github/, but thought it
could be nice to automate those updates through Renovate. The custom
manager will look for any major version GitHub Action reference in any
Markdown file in `docs` directory, and raise a PR to update it.
Possible improvements:
- We could separate those updates from updating the actions updates for
uv's own GitHub Actions workflow, which would end up raising 2 different
PRs instead of grouping them (example of the current behaviour without
this improvement in
https://github.com/mkniewallner/mkv-playground/pull/4 where we update
the doc reference at the same time as a real dependency usage in a
workflow).
- ~Should the PRs be raised immediately, to handle the update as soon as
possible, instead of waiting for the regular weekly Monday schedule?
This would ensure that `astral-sh/setup-uv` references are handled as
early as possible.~ done in
6af7f45750
## Test Plan
I've tested that with
00ddfb6900/renovate.json5
and
00ddfb6900/docs/integeration/foo.md,
where Renovate raised 2 PRs:
- https://github.com/mkniewallner/mkv-playground/pull/13
- https://github.com/mkniewallner/mkv-playground/pull/4
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
## Summary
Closes https://github.com/astral-sh/uv/issues/7458
This change adds a new job at the end of docker publish which adds
annotations the primary image digests in order to make ghcr.io rank
`ghcr.io/astral-sh/uv` at the top once again. The solution is to
annotate the index at the end during a re-publish to make ghcr.io
consider it a more updated entry than the others and rank it at the top
once again.
## Test Plan
Tested on release run on my own fork
* Packages: https://github.com/samypr100/uv/pkgs/container/uv will show
`ghcr.io/astral-sh/uv` first once again
* Run: https://github.com/samypr100/uv/actions/runs/10951404736
## Summary
`#[serde(flatten)]` has a disastrous effect on error messages: serde no
longer tells you which field errored, nor does it show it to you in the
diagnostic output.
Before:
```
warning: Failed to parse `pyproject.toml` during settings discovery:
TOML parse error at line 9, column 1
|
9 | [tool.uv]
| ^^^^^^^^^
invalid type: string "foo", expected a sequence
```
After:
```
warning: Failed to parse `pyproject.toml` during settings discovery:
TOML parse error at line 10, column 19
|
10 | extra-index-url = "foo"
| ^^^^^
invalid type: string "foo", expected a sequence
```
Closes https://github.com/astral-sh/uv/issues/7113.
## Summary
This reverts commit 3060fd22c0.
These are now _never_ shown to users, because `tracing` isn't set up at
that point. I'm going to try and improve the solution more holistically,
but this is better than the status quo.
Closes https://github.com/astral-sh/uv/issues/7573.
This enhances the hints generator in the resolver with some heuristic to
detect and warn in case of failures due to version mismatches on a local
package. Those may be the symptom of name conflict/shadowing with a
transitive dependency.
Closes: https://github.com/astral-sh/uv/issues/7329
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
## Summary
Small stale/typo char in docs when generating a project
```
➜ ntp -v uv-test && uv venv --python 3.12 --seed && uv init --app --package example-packaged-app
Directory /tmp/testing/uv-test created and switched to.
Using Python 3.12.4 interpreter at: /Users/coffee/.local/share/mise/installs/python/3.12/bin/python3.12
Creating virtual environment with seed packages at: .venv
+ pip==24.2
Activate with: source .venv/bin/activate.fish
Virtual environment created with Python 3.12 and activated.
Using Python 3.12.4 interpreter at: /Users/coffee/.local/share/mise/installs/python/3.12/bin/python3.12
Creating virtual environment with seed packages at: .venv
+ pip==24.2
Activate with: source .venv/bin/activate.fish
Initialized project `example-packaged-app` at `/private/tmp/testing/uv-test/example-packaged-app`
/tmp/testing/uv-test via pyenv (uv-test) on ☁ (us-east-2)
➜ tree
0 B ┌─ README.md
4096 B ├─ pyproject.toml
4096 B │ ┌─ __init__.py
4096 B │ ┌─ example_packaged_app
4096 B ├─ src
8192 B ┌─ example-packaged-app
8192 B uv-test
```
## Test Plan
Eyeballs
## Summary
Because a problem was found with Powershell and combining the generated
completion scripts for uv and uvx, let's try separating uv and uvx
command completion scripts.
The generated powershell script template can be seen in clap_complete
source, and it starts with `using` directives, which makes it impossible
(apparently) to concatenate two of those script outputs.
As a side effect, this is available under `uv tool run
--generate-shell-completion` too.
Fixes#7482
## Test Plan
- `eval "$(cargo run --bin uvx -- --generate-shell-completion bash)"`
- Test Powershell
## Summary
The AGPL license is confusing some analyzers. This replaces pretix with
saleor which (similarly) is a web application.
Closes https://github.com/astral-sh/uv/issues/7566.
## Summary
`uv cache prune --ci` will remove the source distribution directory. If
we then need to build a _different_ wheel (e.g., you're building a
package that has Python minor version-specific wheels), we fail, because
we expect the source to be there.
Now, if the source is missing, we re-download it. It would be slightly
easier to just _ignore_ that revision, but that would mean we'd also
lose the already-built wheels -- so if you ran against many Python
versions, we'd continuously lose the cached data.
Closes https://github.com/astral-sh/uv/issues/7543.
## Test Plan
We can add tests, but they _need_ to build non-pure Python wheels, which
tends to be expensive...
For reference:
```console
$ cargo run venv --python 3.12
$ cargo run pip install mercurial==6.8.1 --verbose
$ cargo run cache prune --ci
$ cargo run venv --python 3.11
$ cargo run pip install mercurial==6.8.1 --verbose
```
I also did this with a local `.tar.gz` that I downloaded from PyPI.
## Summary
Both of these can contain rkyv data in their HTTP cache envelopes. As
such, the entries aren't readable by earlier versions of uv, and `uv
cache prune` can break. I should make `uv cache prune` robust to this,
but this feels safest.
## Summary
I think this is just inverted. It means that when we fail in
https://github.com/astral-sh/uv/issues/7553, we show a message for
"invalid Python implementation" (since there are some wheels that don't
match), but we should be showing "invalid platform", matching the order
of operations in our compatibility check.
Closes https://github.com/astral-sh/uv/issues/7553.
Adds display of the target path of the link (since the link filename
itself is basically static) and distinguishes between broken links and
missing files.
## Summary
Improve the description of override-dependencies based on the statement
in `concepts/resolution.md`: "As with constraints, overrides do not add
a dependency on the package and only take effect if the package is
requested in a direct or transitive dependency."
I tested it locally, `concepts/resolution.md` is correct. It would be
better to also include this in the Reference Chapter of the docs.
I think it's best practice to use a placeholder when we transform
something, and #7522 is having snapshot issues because this filter
conflicts with `with_filtered_virtualenv_bin`
As we support more complex Python discovery behaviors such as:
- #7431
- #7335
- #7300
`Any` is no longer accurate, we actually are looking for a reasonable
default Python version to use which may exclude the first one we find.
Separately, we need the idea of `Any` to improve behavior when listing
versions (e.g., #7286) where we do actually want to match _any_ Python
version. As a first step, we'll rename `Any` to `Default`. Then, we'll
introduce a new `Any` that actually behaves as we'd expect.
Recently, rkyv 0.8 was released. Its API is a fair bit simpler now for
higher level uses (like for us in `uv`) and results in us being able to
delete a fair bit of code. This also removes our last dependency on `syn
1.0`, and thus drops that dependency.
Performance (via testing on the `transformers` example) seems to remain
about the same, which is what was expected:
```
$ hyperfine -w5 -r100 'uv lock' 'uv-ag-rkyv-update lock'
Benchmark 1: uv lock
Time (mean ± σ): 55.6 ms ± 6.4 ms [User: 30.4 ms, System: 35.1 ms]
Range (min … max): 43.0 ms … 73.1 ms 100 runs
Benchmark 2: uv-ag-rkyv-update lock
Time (mean ± σ): 56.5 ms ± 7.2 ms [User: 30.5 ms, System: 36.3 ms]
Range (min … max): 39.1 ms … 71.5 ms 100 runs
Summary
uv lock ran
1.02 ± 0.18 times faster than uv-ag-rkyv-update lock
```
Closes#7415
## Summary
This adds about 50 KB to the binary:
```
❯ du ./target/release/socks
44736 ./target/release/socks
❯ du ./target/release/uv
44632 ./target/release/uv
```
So need some input on whether it's worth supporting.
Closes https://github.com/astral-sh/uv/issues/7484.
This changes the structure of the hints generator in the resolver when
encountering solution errors, so that it re-uses a single output buffer
owned by the caller.
It avoids repeated allocations of a temporary buffer within each
recursive function call.
## Summary
See: https://github.com/astral-sh/uv/issues/7485. The test was using `uv
pip sync` which doesn't require fetching metadata, and the failure was
in fetching metadata.
## Summary
Related discussion: #5731
This adds a warning section for caching on non-ephemeral (e.g. ec2) self
hosted github runners.
## Test Plan
Prettier was ran on the file.
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
## Summary
Closes https://github.com/astral-sh/uv/issues/7485.
## Test Plan
```
$ cargo run cache clean
$ cargo run venv
$ cargo run pip install django-allauth==0.51.0
$ cargo run venv
$ cargo run pip install django-allauth==0.51.0
```
