## Summary
<!-- What's the purpose of the change? What does it do, and why? -->
This is a attempt at fixing https://github.com/astral-sh/uv/issues/6486.
It reverts changes made to `pyproject.toml` when sync fails during `uv
add`. This solution felt a little heavy handed and could probably be
improved but it is what happens when locking fails during `uv add` so I
thought it would be a good start.
## Test Plan
<!-- How was it tested? -->
I have added a test case for this to `tests/edit.rs`. It uses
`pytorch==1.0.2` to achieve the desired failure.
<!--
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? -->
While the contents of `ecosystem/` are “merely” `pyproject.toml` files
and one trivial Python script, they are still covered by the licenses of
the projects from which they are copied. Not only is maintaining
license/copyright statements good practice, but it’s generally
specifically required by the particular licenses involved here.
Even though these files are for integration testing only – and therefore
do not contribute to the license of the compiled `uv` executable – they
are nevertheless part of the source archive, so distributors and
integrators need to consider their license status. For example, I
maintain the `uv` package in Fedora Linux, and I need to consider these
licenses because the files would be redistributed in the source RPMs.
## Test Plan
<!-- How was it tested? -->
N/A – validated by examination of the diff.
<!--
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? -->
Document in guide stdin usage
alllll the easter eggs can do as well, but declined to keep consistent
with the other examples 😆
Additions to https://github.com/astral-sh/uv/pull/6481
```bash
$ uv run - <<EOF
import antigravity
EOF
```
## Test Plan
<!-- How was it tested? -->
https://github.com/astral-sh/uv/pull/6519#issuecomment-2307371063 new PR
## Summary
Indicate the previous version from which uv was upgraded when running
`uv self update`. Thought that it could be useful in some situations to
have a trace of the previous version that was installed.
## Test Plan
Did not find a way to test this, since this heavily relies on being able
to use the installation script and the ability to publish artifacts for
a specific tag.
## Summary
Small keyword fix. In the `concepts/dependencies` documentation, the
workspace example listed members under an invalid
`tool.uv.workspace.include` field.
This PR changes the key to
[`tool.uv.workspace.members`](https://docs.astral.sh/uv/reference/settings/#workspace_members)
instead.
<!--
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
Two small typo fixes: one in the documentation and one in a comment in
the source code I happened to come across.
## Summary
We accidentally changed the Windows cache directory from
`C:\Users\User\AppData\Local\uv\cache` to
`C:\Users\User\AppData\Local\uv` in v0.3.0. We're considering this a
bug, since it does _not_ match the documentation, and prior to v0.3.0,
we always used the former. This PR migrates back to the previous
location. It should be seamless for users, as we move the cache items to
the new location on startup.
Closes https://github.com/astral-sh/uv/issues/6417.
While working on https://github.com/astral-sh/uv/pull/6389 I discovered
we never checked `cache.get_url` here, which is wrong — though I don't
think it had much effect in practice since the realm would typically
match first. The main problem is that when we call `get_url` later we
hard-code the username to `None` because we assume we checked up here
with the username if present.
## Summary
This reverts commit 7d92915f3d.
I thought this would be a net performance improvement, but we've now had
multiple reports that this made locking _extremely_ slow. I also tested
this today with a very large codebase against a registry that does not
support range requests, and the number of downloads was sort of wild to
watch. Reverting the reduced resolution time by over 50%.
Closes#6104.
<!--
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? -->
Updated docs dockerfile from Debian 11 (bullseye) to latest stable
Debian 12 (bookworm).
## Test Plan
<!-- How was it tested? -->
<!--
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
Docs at https://docs.astral.sh/uv/pip/compatibility/ still say:
> the future, uv will also support persistent configuration in its own
configuration file format (e.g., pyproject.toml or uv.toml or similar).
For more, see [#651](https://github.com/astral-sh/uv/issues/651).
I think that's done now (?), so updated these to link to
https://docs.astral.sh/uv/configuration/files/
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
## Summary
Mark the new tests requiring Python 3.12.1 specifically as requiring
python-patch feature. This makes the test suite pass again on systems
not having this specific version (and disabling the feature).
## Test Plan
`cargo test` on Gentoo :-).
## Summary
It turns out we weren't applying the collapse logic here, so dev deps
with extras were repeated. This was generally ok... unless we ended up
_dropping_ an extra, in which case, you now have a duplicate.
Closes https://github.com/astral-sh/uv/issues/6380.
In https://github.com/astral-sh/uv/pull/6359, I accidentally made `uv
python install` prefer `.python-version` files over `.python-versions`
files -.-, kind of niche but it's a regression.
