3 ms·
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 environmen
by coeneedell 1y ago
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 1y ago> 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/ https://docs.astral.sh/uv/guides/integration/docker/
- rtpg 1y agohttps://docs.astral.sh/uv/guides/integration/docker/#intermediate-layers 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 1y agoNice 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 11mo agoYeah I see now I was mixing techniques in two sections of that document
- cyberax 1y agoMounting 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 https://github.com/astral-sh/uv/issues/15715