mirror of
https://github.com/astral-sh/uv.git
synced 2025-07-09 22:35:01 +00:00
bf96c60e3e
Surprisingly, we weren't locking during `uv sync` so far, so running `uv sync` in parallel could cause errors in filesystem races. I've also added locks to `uv add` and `uv remove` which concurrently modify `pyproject.toml`. These locks only apply after we determined the interpreter, so they don't actually prevent computing the same thing twice when running `uv add` in parallel. All other subcommands that I checked were already locking (with no claim to exhaustiveness) Fixes #12751 # Test Plan I don't have CI-sized reproducer for this. ```toml [project] name = "debug" version = "0.1.0" requires-python = ">=3.12" dependencies = [ "boto3>=1.38.30", "fastapi>=0.115.12", "numba>=0.61.2", "polars>=1.30.0", "protobuf>=6.31.1", "pyarrow>=20.0.0", "pydantic>=2.11.5", "requests>=2.32.3", "urllib3>=2.4.0", "scikit-learn>=1.6.1", "jupyter>=1.1.1", ] [build-system] requires = ["hatchling"] build-backend = "hatchling.build" ``` ``` rm -rf .venv && parallel -n0 "uv sync -q" ::: {1..10} ``` |
||
|---|---|---|
| .. | ||
| sysconfig | ||
| cpuinfo.rs | ||
| discovery.rs | ||
| downloads.rs | ||
| environment.rs | ||
| implementation.rs | ||
| installation.rs | ||
| interpreter.rs | ||
| lib.rs | ||
| libc.rs | ||
| macos_dylib.rs | ||
| managed.rs | ||
| microsoft_store.rs | ||
| platform.rs | ||
| pointer_size.rs | ||
| prefix.rs | ||
| python_version.rs | ||
| target.rs | ||
| version_files.rs | ||
| virtualenv.rs | ||
| windows_registry.rs | ||