Quick Answer
uv_build uses an uncompressed archive writer for editable wheels. Regular wheels continue to use compressed entries in the accompanying regression test.
In Plain English
An editable installation lets a developer work on source code without rebuilding an ordinary distributable for every edit. Its intermediate wheel has a different job from a package intended for distribution. Compressing a temporary archive and then immediately reading it can add avoidable work.
Code Evidence
In crates/uv-build-backend/src/wheel.rs, build_editable switches from new_wheel to the existing new_editable writer. The new test builds both kinds of wheel and checks entry compression: regular file entries use Deflate in the standard wheel and Stored in the editable wheel. Directory entries remain uncompressed.
Why a Temporary Wheel Has Different Priorities
A wheel is an archive, and an archive writer can choose whether to compress the bytes it places inside. Compression is useful when storage size or distribution bandwidth matters. An editable wheel exists to support an editable installation, where the relationship to the working source tree is central. For that intermediate artifact, spending processing effort to reduce bytes may have less value than it does for a wheel that will be published and downloaded repeatedly.
The patch expresses that distinction at the writer-selection boundary. It uses the existing editable writer instead of adding a separate compression engine or changing the format of ordinary wheels. That makes the change unusually easy to scope: the reviewed code changes how the editable build chooses its archive writer, while the accompanying test checks both editable and standard output. The test’s ordinary-wheel assertions are important because they guard the distribution path against accidentally inheriting the temporary artifact’s storage choice.
A Developer Workflow Where It Can Matter
Imagine a team that frequently recreates development environments while switching branches or checking packaging changes. Each editable build is only one part of the setup sequence, alongside dependency resolution, downloads, installation, and possibly native compilation. Avoiding archive compression removes a category of work inside that build. It does not follow that the entire setup will feel dramatically faster. The fraction of time spent on the archive determines how visible this particular improvement can be.
A different team may keep one editable installation active for long periods and spend most of its time running tests against changed source files. That team could encounter the changed build path far less often. The source provides a reason to expect less compression work when editable wheels are built, but it does not establish how often a particular project rebuilds them or how much CPU time compression previously consumed. This is why an application-specific measurement is more useful than attaching a universal percentage to the release note.
Read the Regression Test as a Boundary
The compression methods give reviewers a concrete property to inspect. Stored means the archive entry is kept without compression; Deflate names the compression method expected for the regular wheel’s file entries. Directory entries remain stored. Separating file and directory assertions avoids treating an archive with a mixture of entry types as though every entry should follow the same rule. The relevant output contract is visible in the archive metadata, rather than inferred from a file-size change.
That evidence is also narrower than a full installation guarantee. A compression assertion does not, by itself, prove that every project layout imports correctly after installation. Existing packaging behavior and a project’s own installation checks remain relevant. The useful reading is that the regression test protects the intended storage method for each build mode. It supplies a precise check for this implementation choice without pretending to measure every aspect of editable installation.
A Practical Measurement Plan
For teams evaluating the upgrade, keep the project, Python version, platform, build configuration, and cache state consistent when comparing editable builds. Record the time spent building the wheel separately from the time needed for an entire environment setup. If downloads or compilation dominate a run, report those costs alongside the build result so they do not hide or exaggerate the effect of the writer change. Repeat measurements enough to recognize ordinary run-to-run variation before drawing conclusions.
Inspect one ordinary wheel and one editable wheel as part of that evaluation, checking compression metadata for file entries rather than assuming archive size proves the method. Then install the editable result in a disposable environment and exercise a representative import or project test. These are suggested adoption checks, not measurements performed for this article. They connect the source-level promise to the packaging behavior a team actually depends on, while preserving the distinction between reduced processing and a quantified speedup.
Why It Matters
Our interpretation is that the implementation now matches the temporary artifact’s role. This is a focused way to reduce unnecessary processing without claiming a new installation model. It does not mean published wheels stop using compression, and it does not establish how much time a particular developer will save.
An Open Question
When does this matter enough to measure? A project with frequent editable builds may see a different result from one dominated by dependency downloads or native compilation. A useful benchmark would keep those other costs visible.
Scope and Limitations
We inspected the writer selection and compression test. We did not benchmark wheel creation. uv lists this change as a performance improvement in 0.12.18, but supplies no universal speedup in the reviewed diff.