feature: Use `uv` for managing plugin virtual envs?
Feature scope
CLI (options, error messages, logging, etc.)
Description
uv^1 is a tool created by the Astral team (of Ruff fame). It's a drop-in replacement for most of the functionality of both pip and virtualenv, but faster (10x-100x).
It's probably not a good idea to think of replacing pip and virtualenv with it this early, but it could initially be added behind a feature flag.
cc @BTheunissen
In particular uv pip install --link-mode=hardlink seems like an interesting option for boosting performance of plugin installation:
--link-mode <LINK_MODE>
The method to use when installing packages from the global cache
[default: clone]
Possible values:
- clone: Clone (i.e., copy-on-write) packages from the wheel into the site packages
- copy: Copy packages from the wheel into the site packages
- hardlink: Hard link packages from the wheel into the site packages
@edgarrmondragon is the clone option only supported on particularly file systems? If so, which ones? What does it fall back to if copy-on-write is not possible, or does it just error instead? Is there a practical risk that the hardlinks break, e.g. if the cache is cleared?
is the
cloneoption only supported on particularly file systems? If so, which ones?
Here's a good summary^1 of OS/FS support:
| OS | FS | Copy command | System call |
|---|---|---|---|
| Linux | Bcachefs | cp --reflink=always |
ficlone |
| Btrfs | |||
| XFS | |||
| OCFS2 | |||
| Ext4 | Unsupported. | ||
| OpenZFS | |||
| FreeBSD | |||
| ZFS | |||
| Solaris | Oracle ZFS | cp -z |
reflink |
| MacOS | APFS | cp -c |
clonefile |
| HFS+ | Unsupported; non-CoW FS. | ||
| Windows | NTFS | ||
| ReFSv2 | Not included. | DUPLICATE_EXTENTS_TO_FILE |
|
And they seem to be using reflink-copy^2, which has the following to say:
At the moment Linux, Android, OSX, iOS, and Windows are supported.
Note: On Windows, the integrity information features are only available on Windows Server editions starting from Windows Server 2012. Client versions of Windows do not support these features. More Information
What does it fall back to if copy-on-write is not possible, or does it just error instead?
Currently it errors. reflink-copy does have a simple copy fallback^3 available and its being reviewed^4 in uv.
Is there a practical risk that the hardlinks break, e.g. if the cache is cleared?
I've only done simple testing so AFAICT they should be pretty safe, i.e. each hardlink is a reference so the same file on disk, and deleting a copy only deletes a reference so deleting uv's cache doesn't affect installed wheels.
https://github.com/astral-sh/uv/issues/313 might not be a deal-breaker if we keep uv optional and instruct users to update their pip_urls if they wanna use uv
UPDATE 2024-03-22: This will be fixed in the next uv release.