[gatvol]

UV is super fast and great for environment management, however it's not at all well suited to a containerised environment, unless I'm missing something fundamental (unless you like using an env in your container that is).

[nickjj]

uv works great in a container, you can tell it to skip creating a venv and use the system's version of Python (in this case, let's say Python 3.14 from the official Python image on the Docker Hub).

The biggest wins are speed and a dependable lock file. Dependencies get installed ~10x faster than with pip, at least on my machine.

Both of my Docker Compose starter app examples for https://github.com/nickjj/docker-flask-example and https://github.com/nickjj/docker-django-example use uv.

I also wrote about making the switch here: https://nickjanetakis.com/blog/switching-pip-to-uv-in-a-dock...

[zahlman]

> unless you like using an env in your container that is

A virtual environment, minimally, is a folder hierarchy and a pyvenv.cfg file with a few lines of plain text. (Generally they also contain a few dozen kilobytes of activation scripts that aren't really necessary here.) If you're willing to incur the overhead of using a container image in the first place, plus the ~35 megabyte compiled uv executable, what does a venv matter?

[scuff3d]

Works fine in containers as far as I can tell. I don't even bother configuring it to not use a venv. Doesn't hurt anything

[bognition]

Why not?

In my docker files I use `uv sync` to install deps vs `pip install -f requirements.txt`

And then set my command to `uv run my_command.py` vs calling Python directly.

[amingilani]

> it's not at all well suited to a containerised environment

Could you elaborate?

[__float]

Why not use a virtualenv in your container?

[emeraldd]

This is still a complete pain to work with. Virtualenv in general is a "worst of worlds" solution. It has a lot of the same problems as just globally pip installing packages, requires a bit of path mangling to work right, or special python configs, etc. In the past, it's also had a bad habit of leaking dependencies, though that was in some weird setups. It's one of the reasons I would recommend against python for much of anything that needs to be "deployed" vs throw away scripts. UV seems to handle all of this much better.

[coeneedell]

I haven’t really had this issue. UV’s recommendation is to mount the uv.lock and install those manages package versions to the container’s global pip environment. We haven’t had much issue at my work, where we use this to auto-manage python developer’s execution environments at scale.

[m000]

> UV’s recommendation is to mount the uv.lock and install those manages package versions to the container’s global pip environment.

Source? That's an option, but it's not even explicitly mentioned in the related documentation [1].

[1] https://docs.astral.sh/uv/guides/integration/docker/

[cyberax]

Mounting uv.lock doesn't actually work if you have intra-repository dependencies. UV can't deal with packages that lack metadata (because it's not mounted): https://github.com/astral-sh/uv/issues/15715

[nomel]

The only reason I haven't switched is its still barely-there support for air-gapped systems [1].

And lack of non-local venv support [2].

[1] https://github.com/astral-sh/uv/issues/10203

[2] https://github.com/astral-sh/uv/issues/1495

[hodanli]

Same here. I still use conda from time to time for this.

[diath]

> (unless you like using an env in your container that is).

What's the problem with that?

You just make your script's entry point be something like this:

    uv venv --clear
    uv sync
    uv run main.py

[nodesocket]

Doesn’t this mean pid 0 in the container is uv instead of python? Does uv run just spawn a child python process?

[nicwolff]

    ENV UV_SYSTEM_PYTHON=1