Hey folks,
I’m currently updating a Flask application that runs in a docker container. Currently it uses pip and a `requirements.txt` file and I’m trying to get dependency management setup with uv.
The Dockerfile brings in this image:
FROM python:3.11.3
I’d like to switch to one of the images here:
What would be the most suitable replacement in this case?
Thanks!
It depends on what your goal is. If minimising container size is important then switching to uv at all is probably going to make it worse. What are your priorities? Size? Auditability? Automated CVE tracking? Symmetry with dev environments? Tight control over dependency versions? Reproducible builds? Do you care which build of Python you get?
The normal Python versions are built on top of Debian, so for consistency pick one of those. I find the Alpine ones work well too, but there can be bugs with MUSL, especially if using C extensions.
I found copying the uv binaries from a distroless uv image (like a kind of pre-built build stage) into whatever image I was using previously, worked OK:
COPY --from=ghcr.io/astral-sh/uv:latest /uv /uvx /bin/
I’d just like to use uv to manage dependencies, nothing fancy.
At this point I have a pyproject.toml file and want to create and use a venv in my container using the usual uv commands, i.e. uv sync
I’m not really sure what the python:3.11.3 image actually contains.
I’m not really sure what the python:3.11.3 image actually contains.
Full fat Debian Buster Image Layer Details - python:3.11.3 (apologies)
Just dependencies or Python itself too?
This is the way. Use whatever slim base image you need and copy in the uv binaries.
This is the way.
I would like to use uv to manage Python versions, yes.
I’d aim for distroless ghcr.io/astral-sh/uv then since any existing Python installations will end up being ignored in favour of the one(s) you get uv to install.
That sounds good. How would I make sure that the container uses the environment created by uv sync ?
Start jobs with uv run in the same dir. Or use --project flags etc. to be sure.
Here’s an example that uses multiple stages to keep uvand build dependencies out of the final image. It uses the official CPython runtime rather than uv managed python-build-standalone
Again, it’s up to you. You can use uv run or prepend .venv/bin to PATH or symlink .venv/bin/{python,flask,anythingelseyouwant} into /usr/bin or just use full paths. It’s distroless and only contains one Python installation so the usual concerns about mixing up Python versions or clobbering system package manager owned files don’t apply.