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