[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/

[rtpg]

https://docs.astral.sh/uv/guides/integration/docker/#interme...

You kind of have to read between the lines and "know" this is a good solution and then when you see it it's like "right of course".

[m000]

Nice tricks! I wasn't aware of the cache mounts, so I was building with UV_NO_CACHE=1. Cache mounts should also come handy when installing OS packages in multi-stage builds.

I still couldn't find the "global pip environment" part, unless by that you meant the "active pip environment", pointed by VIRTUAL_ENV during image building.

[coeneedell]

Yeah I see now I was mixing techniques in two sections of that document

[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