uv is a fast Python package installer and resolver written in rust that is designed to be able to replace both venv and pip.
This is a double request since one doesn’t really make sense without the other, but I’ve split my reasoning for each up.
Reserved name
uv is a reserved name in the snap store (from what I can tell any name under 4 letters is, and that makes sense). However, there doesn’t seem to be a conflict here:
Given that I’m already the publisher for the related tool ruff, I believe it’s reasonable for me (or snapcrafters) to publish uv as well
Classic confinement
uv is a developer tool not unlike node, go, rustup and pyright
While this could potentially walk the line between supported and unsupported snaps under the review process, I believe the best category fit is supported:
tools for local, non-root user driven configuration of/switching to development workspaces/environments
Regarding the snap name, you can alternatively use a longer name (in case that uv stands from something else I couldn’t found) and ask for the uv alias. Otherwise, maybe @odysseus-k@lofidevops can help you to get this name.
Regarding classic confinement, I could see uv fitting in the support category, however I wonder if we could make it to work under strict confinement. The only limitation I can foresee would be that virutal environment folders will need to be placed under the user’s home directory (or any other pre-defined location using system-files). Do you think that this limitation will seriously hamper the usability of this snap or are you already aware of any other limitation?
I’ve registered astral-uv, so once I’ve got stuff fully up and running I’ll request an auto-alias for that
The main limitation with strict confinement here is that pip install (and thus uv pip install) needs to be able to access the compilers on the system. As a quick example, this is what happens when I try to use the strict snap to install cryptography from source (which would be the only way to install it on, for example, riscv64 or s390x):
The error you are observing relates to pip not having access to any c compiler, either the system one or a compiler shipped within the snap.
It should be possible to ship the snap with all the required dependencies (i.e. gcc, rustc, cargo, etc.) so that users don’t need to install them manually (what would improve both security and usability of this snap). I’ve created a quickdemo to draft this idea. The main issue to be solved in this scenario will be to ensure that libraries used to compile the python wheel (i.e. libraries used within the snap) are the same/compatible with libraries used at runtime in the host system.
I’m not sure it would be possible to adequately cover all the possibilities. In addition to what you’ve listed, the snap would need to stage various versions of dotnet, etc.
Some other issues I found while trying to get uv working with strict confinement:
Python executables not also staged in the snap can’t be used when running uv venv:
Binary packages linked against Python.h don’t work unless they’re linked against the same version as on the system (making the default interpreter of /usr/bin/python3 further ambiguous)
python3 in the virtual environments links to the destination within the snap’s environment:
Whilst it should be possible to address all those issues by ensuring that the python interpreter is always called within the snap runtime as I did in the demo I agree that things become non-obvious and it will create a different set of issues.
Thus, requirements for classic are understood, uv fits in tools for local, non-root user driven configuration of/switching to development workspaces/environments and publisher is already vetted. Granting astral-uv snap use of classic.
You will need to remove plugs/slots from your snapcraft.yaml before it can pass automatic-reviews and those properties as not allowed with classic. I will recommend you to create a new forum topic for the alias request as it will be easier to catch reviewers attention this way