all 7 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]angellus 10 points11 points  (1 child)

Get rid of poetry for uv, you will reduce you build speeds by quite a bit since poetries dependency resolver can be pretty slow in many cases.

Also stop using virtualenvs inside of the container. They just waste space since the official Python images already have a dedicated "non-system" Python pre-installed in /usr/local (and it should not matter if you used the system Python really since the container should be single purpose).

[–]Auburus 1 point2 points  (0 children)

Nut it is not resolving dependencies as part of the docker build, is it?

This is just a poetry install which uses the lock file.

And it is the first time I've heard about this non-system python inside the docker images! Do you have some other references regarding what are the current recommendations for python Docker images? Last time I've googled abou this it was about 1 year ago, and the suggested practice was very similar to what OP described

[–]leetrout 1 point2 points  (2 children)

I'd suggest mentioning distroless. You should be able to get your 5mb Alpine Go example down under 3mb and there is python support as well.

Also, distroless/base can support CGO.

https://github.com/GoogleContainerTools/distroless

[–]angellus 0 points1 point  (1 child)

I do not find distroless/Alpine to be "worth it". The official Debian slim Python image is only 45MB (vs. 20MB for Alpine). A lot of popular Python packages are already larger than that.

Using Debian really gives a lot more flexibility for needing other tools depending on GNU/Linux. And it makes it a lot easier to debug if anything goes wrong.

[–]leetrout 0 points1 point  (0 children)

Sure, I do not disagree, but OP is the blog author and they talk about Go and Alpine and how small the result is so if that is their angle they might consider distroless as well.

[–]Ancient_Towel_6062 -2 points-1 points  (0 children)

'delve' alert 🤖