Wrap documentation at 100 characters

CONTRIBUTING.md

@@ -1,6 +1,10 @@
 # Contributing
 
-We have issues labeled as [Good First Issue](https://github.com/astral-sh/uv/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) and [Help Wanted](https://github.com/astral-sh/uv/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) which are good opportunities for new contributors.
+We have issues labeled as [Good First
+Issue](https://github.com/astral-sh/uv/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22)
+and [Help
+Wanted](https://github.com/astral-sh/uv/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22)
+which are good opportunities for new contributors.
 
 ## Setup
 
@@ -26,7 +30,8 @@ See the [Python](#python) section for instructions on installing the Python vers
 
 ### Windows
 
-You can install CMake from the [installers](https://cmake.org/download/) or with `pipx install cmake`.
+You can install CMake from the [installers](https://cmake.org/download/) or with `pipx install
+cmake`.
 
 ## Testing
 
@@ -55,18 +60,23 @@ cargo run -- pip install requests
 
 ### Testing on Windows
 
-When testing debug builds on Windows, the stack can overflow resulting in a `STATUS_STACK_OVERFLOW` error code.
-This is due to a small stack size limit on Windows that we encounter when running unoptimized builds — the release
-builds do not have this problem. We [added a `UV_STACK_SIZE` variable](https://github.com/astral-sh/uv/pull/941) to
-bypass this problem during testing. We recommend bumping the stack size from the default of 1MB to 2MB, for example:
+When testing debug builds on Windows, the stack can overflow resulting in a `STATUS_STACK_OVERFLOW`
+error code. This is due to a small stack size limit on Windows that we encounter when running
+unoptimized builds — the release builds do not have this problem. We [added a `UV_STACK_SIZE`
+variable](https://github.com/astral-sh/uv/pull/941) to bypass this problem during testing. We
+recommend bumping the stack size from the default of 1MB to 2MB, for example:
 
 ```powershell
 $Env:UV_STACK_SIZE = '2000000'
 ```
 
 ## Running inside a Docker container
 
-Source distributions can run arbitrary code on build and can make unwanted modifications to your system (["Someone's Been Messing With My Subnormals!" on Blogspot](https://moyix.blogspot.com/2022/09/someones-been-messing-with-my-subnormals.html), ["nvidia-pyindex" on PyPI](https://pypi.org/project/nvidia-pyindex/)), which can even occur when just resolving requirements. To prevent this, there's a Docker container you can run commands in:
+Source distributions can run arbitrary code on build and can make unwanted modifications to your
+system (["Someone's Been Messing With My Subnormals!" on
+Blogspot](https://moyix.blogspot.com/2022/09/someones-been-messing-with-my-subnormals.html),
+["nvidia-pyindex" on PyPI](https://pypi.org/project/nvidia-pyindex/)), which can even occur when
+just resolving requirements. To prevent this, there's a Docker container you can run commands in:
 
 ```bash
 docker buildx build -t uv-builder -f builder.dockerfile --load .
@@ -75,15 +85,20 @@ cargo build --target x86_64-unknown-linux-musl --profile profiling
 docker run --rm -it -v $(pwd):/app uv-builder /app/target/x86_64-unknown-linux-musl/profiling/uv-dev resolve-many --cache-dir /app/cache-docker /app/scripts/popular_packages/pypi_10k_most_dependents.txt
 ```
 
-We recommend using this container if you don't trust the dependency tree of the package(s) you are trying to resolve or install.
+We recommend using this container if you don't trust the dependency tree of the package(s) you are
+trying to resolve or install.
 
 ## Profiling and Benchmarking
 
-Please refer to Ruff's [Profiling Guide](https://github.com/astral-sh/ruff/blob/main/CONTRIBUTING.md#profiling-projects), it applies to uv, too.
+Please refer to Ruff's [Profiling
+Guide](https://github.com/astral-sh/ruff/blob/main/CONTRIBUTING.md#profiling-projects), it applies
+to uv, too.
 
-We provide diverse sets of requirements for testing and benchmarking the resolver in `scripts/requirements` and for the installer in `scripts/requirements/compiled`.
+We provide diverse sets of requirements for testing and benchmarking the resolver in
+`scripts/requirements` and for the installer in `scripts/requirements/compiled`.
 
-You can use `scripts/benchmark` to benchmark predefined workloads between uv versions and with other tools, e.g., from the `scripts/benchmark` directory:
+You can use `scripts/benchmark` to benchmark predefined workloads between uv versions and with other
+tools, e.g., from the `scripts/benchmark` directory:
 
 ```shell
 uv run resolver \
@@ -96,7 +111,9 @@ uv run resolver \
 
 ### Analyzing concurrency
 
-You can use [tracing-durations-export](https://github.com/konstin/tracing-durations-export) to visualize parallel requests and find any spots where uv is CPU-bound. Example usage, with `uv` and `uv-dev` respectively:
+You can use [tracing-durations-export](https://github.com/konstin/tracing-durations-export) to
+visualize parallel requests and find any spots where uv is CPU-bound. Example usage, with `uv` and
+`uv-dev` respectively:
 
 ```shell
 RUST_LOG=uv=info TRACING_DURATIONS_FILE=target/traces/jupyter.ndjson cargo run --features tracing-durations-export --profile profiling -- pip compile scripts/requirements/jupyter.in
@@ -157,15 +174,17 @@ To preview any changes to the documentation locally:
 The documentation should then be available locally at
 [http://127.0.0.1:8000/uv/](http://127.0.0.1:8000/uv/).
 
-To update the documentation dependencies, edit `docs/requirements.in` and `docs/requirements-insiders.in`, then run:
+To update the documentation dependencies, edit `docs/requirements.in` and
+`docs/requirements-insiders.in`, then run:
 
 ```shell
 uv pip compile docs/requirements.in -o docs/requirements.txt --universal -p 3.12
 uv pip compile docs/requirements-insiders.in -o docs/requirements-insiders.txt --universal -p 3.12
 ```
 
-Documentation is deployed automatically on release by publishing to the [Astral documentation](https://github.com/astral-sh/docs)
-repository, which itself deploys via Cloudflare Pages.
+Documentation is deployed automatically on release by publishing to the [Astral
+documentation](https://github.com/astral-sh/docs) repository, which itself deploys via Cloudflare
+Pages.
 
 ## Releases
 
@@ -183,6 +202,7 @@ Then, open a pull request e.g. `Bump version to ...`.
 
 Binary builds will automatically be tested for the release.
 
-After merging the pull request, run the [release workflow](https://github.com/astral-sh/uv/actions/workflows/release.yml)
-with the version tag. **Do not include a leading `v`**.
-The release will automatically be created on GitHub after everything else publishes.
+After merging the pull request, run the [release
+workflow](https://github.com/astral-sh/uv/actions/workflows/release.yml) with the version tag. **Do
+not include a leading `v`**. The release will automatically be created on GitHub after everything
+else publishes.

STYLE.md

@@ -1,6 +1,7 @@
 # Style guide
 
-_The following is a work-in-progress style guide for our user-facing messaging in the CLI output and documentation_.
+_The following is a work-in-progress style guide for our user-facing messaging in the CLI output and
+documentation_.
 
 ## General
 
@@ -9,9 +10,12 @@ _The following is a work-in-progress style guide for our user-facing messaging i
 1. Always wrap em-dashes in spaces, e.g., "hello — world" not "hello—world".
 1. Hyphenate compound words, e.g., use "platform-specific" not "platform specific".
 1. Use backticks to escape: commands, code expressions, package names, and file paths.
-1. Use less than and greater than symbols to wrap bare URLs, e.g., `<https://astral.sh>` (unless it is an example; then, use backticks).
+1. Use less than and greater than symbols to wrap bare URLs, e.g., `<https://astral.sh>` (unless it
+   is an example; then, use backticks).
 1. Avoid bare URLs outside of reference documentation, prefer labels, e.g., `[name](url)`.
-1. If a message ends with a single relevant value, precede it with a colon, e.g., `This is the value: value`. If the value is a literal, wrap it in backticks.
+1. If a message ends with a single relevant value, precede it with a colon, e.g., `This is the
+   value: value`. If the value is a literal, wrap it in backticks.
+1. Markdown files should be wrapped at 100 characters
 
 ## Styling uv
 
@@ -82,12 +86,14 @@ The documentation is divided into:
 
 ## CLI
 
-1. Do not use periods at the end of sentences :), unless the message spans more than a single sentence.
+1. Do not use periods at the end of sentences :), unless the message spans more than a single
+   sentence.
 1. May use the second-person point of view, e.g., "Did you mean...?".
 
 ### Colors and style
 
-1. All CLI output must be interpretable and understandable _without_ the use of color and other styling. (For example: even if a command is rendered in green, wrap it in backticks.)
+1. All CLI output must be interpretable and understandable _without_ the use of color and other
+   styling. (For example: even if a command is rendered in green, wrap it in backticks.)
 1. `NO_COLOR` must be respected when using any colors or styling.
 1. `UV_NO_PROGRESS` must be respected when using progress-styling like bars or spinners.
 1. In general, use:

docs/concepts/cache.md

@@ -2,59 +2,62 @@
 
 ## Dependency caching
 
-uv uses aggressive caching to avoid re-downloading (and re-building dependencies) that have
-already been accessed in prior runs.
+uv uses aggressive caching to avoid re-downloading (and re-building dependencies) that have already
+been accessed in prior runs.
 
 The specifics of uv's caching semantics vary based on the nature of the dependency:
 
 - **For registry dependencies** (like those downloaded from PyPI), uv respects HTTP caching headers.
-- **For direct URL dependencies**, uv respects HTTP caching headers, and also caches based on
-  the URL itself.
-- **For Git dependencies**, uv caches based on the fully-resolved Git commit hash. As such,
-  `uv pip compile` will pin Git dependencies to a specific commit hash when writing the resolved
-  dependency set.
+- **For direct URL dependencies**, uv respects HTTP caching headers, and also caches based on the
+  URL itself.
+- **For Git dependencies**, uv caches based on the fully-resolved Git commit hash. As such, `uv pip
+  compile` will pin Git dependencies to a specific commit hash when writing the resolved dependency
+  set.
 - **For local dependencies**, uv caches based on the last-modified time of the source archive (i.e.,
   the local `.whl` or `.tar.gz` file). For directories, uv caches based on the last-modified time of
   the `pyproject.toml`, `setup.py`, or `setup.cfg` file.
 
-It's safe to run multiple uv commands concurrently, even against the same virtual environment.
-uv's cache is designed to be thread-safe and append-only, and thus robust to multiple concurrent
-readers and writers. uv applies a file-based lock to the target virtual environment when installing,
-to avoid concurrent modifications across processes.
+It's safe to run multiple uv commands concurrently, even against the same virtual environment. uv's
+cache is designed to be thread-safe and append-only, and thus robust to multiple concurrent readers
+and writers. uv applies a file-based lock to the target virtual environment when installing, to
+avoid concurrent modifications across processes.
 
-Note that it's _not_ safe to modify the uv cache (e.g., `uv cache clean`) while other uv commands are
-running, and _never_ safe to modify the cache directly (e.g., by removing a file or directory).
+Note that it's _not_ safe to modify the uv cache (e.g., `uv cache clean`) while other uv commands
+are running, and _never_ safe to modify the cache directly (e.g., by removing a file or directory).
 
 If you're running into caching issues, uv includes a few escape hatches:
 
 - To force uv to revalidate cached data for all dependencies, run `uv pip install --refresh ...`.
-- To force uv to revalidate cached data for a specific dependency, run, e.g., `uv pip install --refresh-package flask ...`.
+- To force uv to revalidate cached data for a specific dependency, run, e.g., `uv pip install
+  --refresh-package flask ...`.
 - To force uv to ignore existing installed versions, run `uv pip install --reinstall ...`.
 
 ## Clearing the cache
 
 uv provides a few different mechanisms for removing entries from the cache:
 
 - `uv cache clean` removes _all_ cache entries from the cache directory, clearing it out entirely.
-- `uv cache clean ruff` removes all cache entries for the `ruff` package, useful for invalidating the cache for a
-   single or finite set of packages.
-- `uv cache prune` removes all _unused_ cache entries. For example, the cache directory may contain entries created in
-   previous uv versions that are no longer necessary and can be safely removed. `uv cache prune` is safe to
-   run periodically, to keep the cache directory clean.
+- `uv cache clean ruff` removes all cache entries for the `ruff` package, useful for invalidating
+   the cache for a single or finite set of packages.
+- `uv cache prune` removes all _unused_ cache entries. For example, the cache directory may contain
+   entries created in previous uv versions that are no longer necessary and can be safely removed.
+   `uv cache prune` is safe to run periodically, to keep the cache directory clean.
 
 ## Caching in continuous integration
 
-It's common to cache package installation artifacts in continuous integration environments (like GitHub Actions or
-GitLab CI) to speed up subsequent runs.
+It's common to cache package installation artifacts in continuous integration environments (like
+GitHub Actions or GitLab CI) to speed up subsequent runs.
 
-By default, uv caches both the wheels that it builds from source and the pre-built wheels that it downloads directly,
-to enable high-performance package installation.
+By default, uv caches both the wheels that it builds from source and the pre-built wheels that it
+downloads directly, to enable high-performance package installation.
 
-However, in continuous integration environments, persisting pre-built wheels may be undesirable. With uv, it turns out
-that it's often faster to _omit_ pre-built wheels from the cache (and instead re-download them from the registry on each
-run). On the other hand, caching wheels that are built from source tends to be worthwhile, since the wheel building
-process can be expensive, especially for extension modules.
+However, in continuous integration environments, persisting pre-built wheels may be undesirable.
+With uv, it turns out that it's often faster to _omit_ pre-built wheels from the cache (and instead
+re-download them from the registry on each run). On the other hand, caching wheels that are built
+from source tends to be worthwhile, since the wheel building process can be expensive, especially
+for extension modules.
 
-To support this caching strategy, uv provides a `uv cache prune --ci` command, which removes all pre-built wheels from
-the cache but retains any wheels that were built from source. We recommend running `uv cache prune --ci` at the end of
-your continuous integration job to ensure maximum cache efficiency.
+To support this caching strategy, uv provides a `uv cache prune --ci` command, which removes all
+pre-built wheels from the cache but retains any wheels that were built from source. We recommend
+running `uv cache prune --ci` at the end of your continuous integration job to ensure maximum cache
+efficiency.