[sc077y]

By default it will create hard links for python packages, so it won't consume any more memory (besides the small overhead of hard links).

[zahlman]

As far as I can tell, this only applies to the wheel contents, not to the .pyc bytecode cache created by the interpreter. If you use the defaults, Python will just create per-environment copies on demand; if you precompile with `--compile-bytecode`, uv will put the results directly in the installed copy rather than caching them and hard-linking from there.

I plan on offering this kind of cached precompiled bytecode in PAPER, but I know that compiled bytecode includes absolute paths (used for displaying stack traces) that will presumably then refer to the cached copies. I'll want to test as best I can that this doesn't break anything more subtle.

[Hackbraten]

Unless it can't because you happen to have mounted your user cache directory from a different volume in an attempt to debloat your hourly backups.

[sc077y]

In that case, you use copy OR what you can can also do, if you really care about disk usage, is use symbolic links between the drives. have a .venv sym link on drive A (raid 1) point to the uv_cache_dir's venv on drive B (raid 0). I have not tested though what happens when you unmount and sync.

[zahlman]

... your hourly backups aren't also using the same hard-linking strategy?