Adding Python to Docker in 2 seconds using uv's Python command

Posted by mikeckennedy@reddit | Python | View on Reddit | 42 comments

Had great success speeding up our Docker workflow over at Talk Python using the brand new features of uv for managing Python and virtual environments. Wrote it up if you're interested:

https://mkennedy.codes/posts/python-docker-images-using-uv-s-new-python-features/

[-]

jaarsi_@reddit

Yeah, I’m using this way and works nice

[-]

violentlymickey@reddit

Hmm this is interesting. I'm wondering if it's worth migrating from poetry to uv for our package management. We also use docker to containerize images for CI/docker compose local stacks.

[-]

uv is very fast, PEP compliant (unlike poetry), and stable. Not sure whether installing Python using it makes sense, I just use an appropriate Debian (yes, Alpine is smaller, but musl has caused headaches for me, and Ubuntu isn't as good at patching vulnerabilities and keeping configs close to default) image, such as python:3.12-bookworm-slim.

[-]

ethsy@reddit

What kind of headaches does musl cause?

[-]

code_mc@reddit

musl is NOT optimized for performance, but rather for image size. Not as relevant for python but I still rather take the extra performance over saving a couple MBs in my image size

[-]

ac130kz@reddit

Incompatible libraries, dependency compilation fails, and as others mentioned glibc compatibility breakages too. Surprisingly enough, I've seen a few posts mentioning lower performance on musl. It probably offers better safety and image size, due to simpler code, but I'm not sure it's worth it in the end.

[-]

UloPe@reddit

Locale support is almost nonexistent, some programs that expect glibc break in fun and interesting ways

[-]

FitBoog@reddit

uv yet doesn't handle musl Python binaries well unless it's already pre installed.

[-]

joreilly86@reddit

I moved from Poetry to uv and it's been a relatively seamless transition. Most of my projects are data science and engineering type work. uv has been a breath of fresh air so far, really liking it so far.

[-]

leddy231@reddit

We switched from Poetry to UV at work. The features are the same so the switch was easy, and what you gain is speed and ergonomics. Updating our ~10 package In the monorepo after a dependency upgrade went from minutes to seconds. Might not sound that important, but in the long run it makes updating dependencies less painful, which is good for your repos health.

[-]

Time-Plum-7893@reddit

We use UV in our prod eviromen

[-]

mr_claw@reddit

Same

[-]

rohanjaswal2507@reddit

Could someone please explain to me in simple terms how a tool written in Rust is speeding up python installs?

[-]

richieadler@reddit

The dependency resolution algorithm is ran at native speeds, and the downloads are aggresively cached so every installation helps speeding the other ones.
The (re)creation of virtual environments is blazingly fast. If you picked the wrong Python for your venv, you just pass the correct version in the command line, and it's created again almost immediately. (Unless you don't have the version indicated, if it's valid and it's available it will download it and install it for you.)

[-]

rohanjaswal2507@reddit

So, of the dependency resolution is done at native speeds, what other aspects are fastened up? And deps resolution is the one that takes majority of the time. So, I am still not able to get it how the performance improvements are achieved.

[-]

mgedmin@reddit

uv also caches installed packages and uses hardlinks to make them available in new virtualenvs. This speeds up installation.

(Also, this is configurable if you don't like hardlinks.)

[-]

richieadler@reddit

the dependency resolution is done at native speeds

(for what I mean executable program speeds, maybe I used the wrong word here)

deps resolution is the one that takes majority of the time

I am still not able to get it how the performance improvements are achieved.

I think you answered your own questions. If the operations which consume most of the time are the fastest, what's the doubt?

[-]

draeath@reddit

Are you building a fresh image every time? Why not bake python into a common base image that you then FROM ... with?

[-]

failbaitr@reddit

Because people don't understand that OCI-images are layered. And think their layer is the only one they can add.

[-]

ColdPorridge@reddit

If it takes 2 seconds does it even matter?

[-]

britishbanana@reddit

Yeah this is the real value prop from uv - if you can install dependencies in seconds, it becomes trivial to create new environments on the fly, even just to run single commands. This very much challenges previous best practices built in the context that virtual environments are prohibitively expensive to spin up.

[-]

WJMazepas@reddit

I tried making uv work in building the Docker image of my teams service, but with pip we needed to change some certifications and settings on pip to connect to our company's download center and get it from there.

I couldn't get it working with uv, so we are stuck with pip. It's a shame because it does take a few minutes to build all

[-]

Daneark@reddit

Was it certificate issues? Did you try the native tls option?

[-]

CyberWiz42@reddit

Is there a preferred github for uv as well? I’ve found a few, but none of the ones I saw seem very popular.

[-]

proggob@reddit

Thanks - I was using another one but this one looks like it’s maintained by Astral.

[-]

mehmet_okur@reddit

The multiple-python-version management is interesting. I'm a heavy pyenv user. Any other pyenv users thinking about giving this a shot? I have been loving uv and if it's new version management is on par with pyenv, I'm looking forward to this

[-]

britishbanana@reddit

Yes I can't wait to drop pyenv for this. Listened to a talk python to me episode with Charlie Marsh yesterday and now all I want to do on Monday is replace poetry and pyenv with uv.

[-]

Strings@reddit

Removed pyenv from my setup completely now, so you should be grand.

[-]

TripleBogeyBandit@reddit

What’s the TLDR on this tool?

[-]

britishbanana@reddit

It's blazingly fast

[-]

notParticularlyAnony@reddit

Cargo but for python. Use it or be left behind.

[-]

mdrjevois@reddit

Started as better pip/pip-tools/venv. Well on its way to also being a better poetry/rye/pdm/hatch

[-]

hbar340@reddit

uv go vroom

[-]

UnionCounty22@reddit

Holy smokes! Love the show man! I binge it on work days. Will have to get your course soon!

[-]

TankBo@reddit

uv indeed is great. Would like to throw in devenv.sh if you even need more deps and services for local development, CI and production.

[-]

nickN42@reddit

Any reason for not starting with Python base image?

[-]

Salfiiii@reddit

How does uv document/management the installed packages? Is there something similar like the pyproject.toml file in poetry?

[-]

rover_G@reddit

uv uses pyproject.toml by default and updates [project].dependencies when you install packages with uv add. It also supports optional and development dependencies.

[-]

richieadler@reddit

uv uses the PEP-compliant project.dependencies table instead of the proprietary tool.poetry.dependencies to keep track of dependencies, and it stores the pinned versions in the file uv.lock.

Commands uv add and uv remove handle the addition to pyproject.toml; uv sync installs dependencies and even creates the venv if you have used those commands to autocreate the uv.lock file.

As mentioned elsewhere, you can also choose the pip-tools route with uv pip compile and uv pip install.

[-]

Gushys@reddit

I've been experimenting with uv at work on some smaller projects. You can add your dependencies to your pyproject.toml, but it's also compatible with pip commands/bindings

[-]

chinnu34@reddit

I liked uv but for me the downside is lack of prebuilt binaries for ML. If astral can bring it closer to pip/conda for ML, I will surely shift to UV.