There's no information about uv in the comparison of packaging tools

[MarieRoald]

It would be helpful with some information about uv in the build system comparison (or at least a banner that acknowledges that uv exists and that it will be added to this list soon or when the build backend is out of preview).

There are a couple of gotcha’s with uv:

• Libraries in the virtual environments are hardlinked, so if multiple environments have the same version of the same library, then the files in the venv are hardlinked by default, so a change in one venv will affect the other. (This is only a problem if you edit modules in site-packages).
• Uv will not compile dependencies to bytecode by default, so the first time you import a module, it takes longer. This is not a problem for development, but if anyone is containerising their app, then they should be aware of this.

[lwasser]

@MarieRoald a question about the hard linking part. Is that because UV installs tools (similar to pipx) in a global environment? We definitely plan to add UV (and pixi) to our guide!!

Pr's are welcome from anyone who sees this open issue!!

[MarieRoald]

As far as I understand, it's about performance. Uv has a global installation cache where all dependencies are installed. Then, when you add a dependency to a virtual environment, it will, by default, be hard linked to the cache (it seems like it's a copy-on-write on MacOS). Here are a couple of relevant pages in the docs: https://docs.astral.sh/uv/reference/settings/#link-mode and https://docs.astral.sh/uv/concepts/cache/.

The cache leads to almost instant environment setup for cached dependencies and a smaller disk footprint, but modifying files in site-packages can be dangerous.

[yngvem]

I believe PDM has the same feature, but opt-in instead of opt-out, which I think is a good solution (I haven't tested it though): https://pdm-project.org/en/latest/usage/config/#central-installation-caches

[tomato-gits]

I'm at the 2025 SciPy sprint, and I'd like to do some work on this issue.

[SanketKumarKar]

Here’s information you can include or note for adding uv to the build system comparison, along with a suggested banner acknowledging its current status:

Banner Suggestion
⚡️ Note on uv:
The uv build backend from Astral is in active development and currently in preview. It is not yet featured in this build system comparison table. Once its build backend exits preview or its API stabilizes, detailed coverage will be added here.

Key Considerations & Gotchas for uv
Hardlinked Libraries in Virtual Environments

By default, uv creates hardlinks for libraries in virtual environments. This means if you have multiple uv-managed environments with the same version of a library, changing the files in one environment’s site-packages can impact all other environments sharing that hardlink. This is only an issue if you directly edit installed packages—a rare but occasionally important concern, especially for developers who frequently "hotfix" dependencies locally.

Bytecode Compilation

uv does not compile dependencies to Python bytecode (.pyc files) at install time. As a result, the first import of any module will generate bytecode and thus run more slowly. This has little impact in typical development, but is worth flagging for anyone shipping a containerized application: cold start after deployment may have extra overhead unless bytecode is pre-compiled.

Build Backend Status

As of July 2025, uv’s build backend is labeled as "preview". It is not yet universally recommended for all production workflows, and some features or behaviors may change before general availability.

When adding uv to the build system comparison, these points are important to cover in its entry and in usage notes. For now, a short banner like the one above can proactively inform users that this new backend exists and will be added soon.