Request for reserved name and classic confinement: `uv`

[lengau]

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:

• No ubuntu packages would be confused
• Nor Debian packages
• The closest match in AUR is this app

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

[jslarraz]

Hi @lengau

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?

Thanks

[lengau]

Hi, thanks for the response!

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):

uv pip install --no-binary :all: --no-cache cryptography

$ uv pip install --no-binary :all: --no-cache cryptography
Resolved 3 packages in 311ms
error: Failed to download distributions
  Caused by: Failed to fetch wheel: cryptography==42.0.5
  Caused by: Failed to build: cryptography==42.0.5
  Caused by: Failed to install requirements from build-system.requires (install)
  Caused by: Failed to download and build distributions
  Caused by: Failed to fetch wheel: cffi==1.16.0
  Caused by: Failed to build: cffi==1.16.0
  Caused by: Build backend failed to build wheel through `build_wheel()` with exit status: 1
--- stdout:
running bdist_wheel
running build
running build_py
creating build
creating build/lib.linux-x86_64-cpython-312
creating build/lib.linux-x86_64-cpython-312/cffi
copying src/cffi/__init__.py -> build/lib.linux-x86_64-cpython-312/cffi
copying src/cffi/_imp_emulation.py -> build/lib.linux-x86_64-cpython-312/cffi
copying src/cffi/_shimmed_dist_utils.py -> build/lib.linux-x86_64-cpython-312/cffi
copying src/cffi/api.py -> build/lib.linux-x86_64-cpython-312/cffi
copying src/cffi/backend_ctypes.py -> build/lib.linux-x86_64-cpython-312/cffi
copying src/cffi/cffi_opcode.py -> build/lib.linux-x86_64-cpython-312/cffi
copying src/cffi/commontypes.py -> build/lib.linux-x86_64-cpython-312/cffi
copying src/cffi/cparser.py -> build/lib.linux-x86_64-cpython-312/cffi
copying src/cffi/error.py -> build/lib.linux-x86_64-cpython-312/cffi
copying src/cffi/ffiplatform.py -> build/lib.linux-x86_64-cpython-312/cffi
copying src/cffi/lock.py -> build/lib.linux-x86_64-cpython-312/cffi
copying src/cffi/model.py -> build/lib.linux-x86_64-cpython-312/cffi
copying src/cffi/pkgconfig.py -> build/lib.linux-x86_64-cpython-312/cffi
copying src/cffi/recompiler.py -> build/lib.linux-x86_64-cpython-312/cffi
copying src/cffi/setuptools_ext.py -> build/lib.linux-x86_64-cpython-312/cffi
copying src/cffi/vengine_cpy.py -> build/lib.linux-x86_64-cpython-312/cffi
copying src/cffi/vengine_gen.py -> build/lib.linux-x86_64-cpython-312/cffi
copying src/cffi/verifier.py -> build/lib.linux-x86_64-cpython-312/cffi
copying src/cffi/_cffi_include.h -> build/lib.linux-x86_64-cpython-312/cffi
copying src/cffi/parse_c_type.h -> build/lib.linux-x86_64-cpython-312/cffi
copying src/cffi/_embedding.h -> build/lib.linux-x86_64-cpython-312/cffi
copying src/cffi/_cffi_errors.h -> build/lib.linux-x86_64-cpython-312/cffi
running build_ext
building '_cffi_backend' extension
creating build/temp.linux-x86_64-cpython-312
creating build/temp.linux-x86_64-cpython-312/src
creating build/temp.linux-x86_64-cpython-312/src/c
x86_64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -DFFI_BUILDING=1 -I/usr/include/ffi -I/usr/include/libffi -I/tmp/.tmpOhDVmJ/.tmpia0hK2/.venv/include -I/usr/include/python3.12 -c src/c/_cffi_backend.c -o build/temp.linux-x86_64-cpython-312/src/c/_cffi_backend.o
--- stderr:
No working compiler found, or bogus compiler options passed to
    the compiler from Python's standard "distutils" module.  See
    the error messages above.  Likely, the problem is not related
    to CFFI but generic to the setup.py of any Python package that
    tries to compile C code.  (Hints: on OS/X 10.8, for errors about
    -mno-fused-madd see http://stackoverflow.com/questions/22313407/
    Otherwise, see https://wiki.python.org/moin/CompLangPython or
    the IRC channel #python on irc.libera.chat.)

    Trying to continue anyway.  If you are trying to install CFFI from
    a build done in a different context, you can ignore this warning.
    
error: command 'x86_64-linux-gnu-gcc' failed: No such file or directory
---

Thanks,

Alex

[jslarraz]

Hi,

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 quick demo 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.

[lengau]

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:
  
• Python executables that are staged in the snap but not on the system can be used to make a virtual environment that immediately fail:
  
• 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:
  

In short, strict confinement would make uv sufficiently unusable that I’m not sure I’d want to use the snapped version on my own machine.

[jslarraz]

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