## Summary
On Windows, we have a lot of issues with atomic replacement and such.
There are a bunch of different failure modes, but they generally
involve: trying to persist a fail to a path at which the file already
exists, trying to replace or remove a file while someone else is reading
it, etc.
This PR adds locks to all of the relevant database paths. We already use
these advisory locks when building source distributions; now we use them
when unzipping wheels, storing metadata, etc.
Closes#11002.
## Test Plan
I ran the following script:
```shell
# Define the cache directory path
$cacheDir = "C:\Users\crmar\workspace\uv\cache"
# Clear the cache directory if it exists
if (Test-Path $cacheDir) {
Remove-Item -Recurse -Force $cacheDir
}
# Create the cache directory again
New-Item -ItemType Directory -Force -Path $cacheDir
# Define the command to run with --cache-dir flag
$command = {
param ($venvPath)
# Create a virtual environment in the specified path with --python
uv venv $venvPath
# Run the pip install command with --cache-dir flag
C:\Users\crmar\workspace\uv\target\profiling\uv.exe pip install flask==1.0.4 --no-binary flask --cache-dir C:\Users\crmar\workspace\uv\cache -v --python $venvPath
}
# Define the paths for the different virtual environments
$venv1 = "C:\Users\crmar\workspace\uv\venv1"
$venv2 = "C:\Users\crmar\workspace\uv\venv2"
$venv3 = "C:\Users\crmar\workspace\uv\venv3"
$venv4 = "C:\Users\crmar\workspace\uv\venv4"
$venv5 = "C:\Users\crmar\workspace\uv\venv5"
# Start the command in parallel five times using Start-Job, each with a different venv
$job1 = Start-Job -ScriptBlock $command -ArgumentList $venv1
$job2 = Start-Job -ScriptBlock $command -ArgumentList $venv2
$job3 = Start-Job -ScriptBlock $command -ArgumentList $venv3
$job4 = Start-Job -ScriptBlock $command -ArgumentList $venv4
$job5 = Start-Job -ScriptBlock $command -ArgumentList $venv5
# Wait for all jobs to complete
$jobs = @($job1, $job2, $job3, $job4, $job5)
$jobs | ForEach-Object { Wait-Job $_ }
# Retrieve the results (optional)
$jobs | ForEach-Object { Receive-Job -Job $_ }
# Clean up the jobs
$jobs | ForEach-Object { Remove-Job -Job $_ }
```
And ensured it succeeded in five straight invocations (whereas on
`main`, it consistently fails with a variety of different traces).
There should be two functional changes here:
- If we receive SIGINT twice, forward it to the child process
- If the `uv run` child process changes its PGID, then forward SIGINT
Previously, we never forwarded SIGINT to a child process. Instead, we
relied on shell to do so.
On Windows, we still do nothing but eat the Ctrl-C events we receive.
I cannot see an easy way to send them to the child.
The motivation for these changes should be explained in the comments.
Closes https://github.com/astral-sh/uv/issues/10952 (in which Ray
changes its PGID)
Replaces the (much simpler) #10989 with a more comprehensive approach.
See https://github.com/astral-sh/uv/pull/6738#issuecomment-2315451358
for some previous context.
## Summary
When a `pyproject.toml` `[tool.uv.sources.(package)]` section specifies
`workspace` and one or more of (`index`, `git`, `url`, `path`, `rev`,
`tag`, `branch`, `editable`), running `uv` to build or sync the package
gives the error:
```
cannot specify both `index` and `(parameter name)`
```
The error should actually say:
```
cannot specify both `workspace` and `(parameter name)`
```
## Test Plan
I ran `cargo test`, and all tests still passed.
## Add activation commands for fish shell and other alternative shells
While trying to use uv with fish shell, I encountered an issue as
`source .venv/bin/activate` didn't work. The documentation didn't
specify that fish shell requires using `source .venv/bin/activate.fish`
instead. I created issue #10986 to address this.
This PR improves the documentation by:
- Adding the correct activation command for fish shell: `source
.venv/bin/activate.fish`
- Adding the correct activation command for Nushell: `use
.venv\Scripts\activate.nu`
- Adding the correct activation command for Tcsh: `use
.venv/bin/activate.csh`
This will help users of alternative shells to properly activate their
virtual environments without encountering the same confusion I
experienced.
Fixes#10986
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
## Summary
I think the "available versions" may not filter on `--exclude-newer`,
since it's marked as an incompatibility? In which case, this error
message can change as versions are published.
<!--
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? -->
As requested in https://github.com/astral-sh/uv/issues/6565, this adds a
tip discussing the ability to pin the image to a specific SHA digest and
why it may be useful.
## Test Plan
<!-- How was it tested? -->
Start serving the documentation locally
```shell
uvx --with-requirements docs/requirements.txt -- mkdocs serve -f mkdocs.public.yml
```
Then navigate to http://127.0.0.1:8000/uv/guides/integration/docker/ to
see the tool tip being rendered properly
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
Zanie Blue
Charlie Marsh
Andrew Gallant
micolous
Aria Desires
konsti
Cédric
Ryan
renovate[bot]
Paul
吴小白