First, I would like to thank the community members who have been maintaining the Python docker images, it's one of those thankless opensource infrastructure volunteer roles that they've been doing for a long time. Unfortunately Docker assigns the title "Official Image" for various community run images, which creates a misconception on the guarantees being provided, and if I were a suspicious person I would say Docker creates this misconception on purpose to both get free work from community members and make Docker seem more supported by third party organizations than it actually is.
On the topic of python-build-standalone, I've been using it in production for several months now and I'm fairly happy with it. However, one minor reproducibility issue I have when installing python-build-standalone via uv, is that uv does not have an ability to pin to a specific build between uv versions, as uv hard codes a mapping of Python version and platform to a specific build and then updates that mapping between releases. So, updating the version of uv between runs, or having two users run different versions of uv to initialize the environment can change the results. While normally such build changes are trivial, if you look at the uv 0.7.8 and 0.7.9 changelogs you will see that sometimes they can have significant impact: https://github.com/astral-sh/uv/releases/tag/0.7.8. Also, this email finally prompted make an issue on this topic: https://github.com/astral-sh/uv/issues/14263. There are other ways to source python-build-standalone, such as pbs-installer or writing your own script, but I've not yet spent any time investigating them, so I can't comment on them. Damian -----Original Message----- From: Jarek Potiuk <ja...@potiuk.com> Sent: Wednesday, June 25, 2025 10:44 AM To: dev@airflow.apache.org Subject: [DISCUSS] Switching base Python container images to python-standalone ? Hello here, Together with Aritra we are looking into adding a few more things to our images (golang tool chain for CI image), also Shahar is experimenting with Rust tool chain and I also recently realized (by some of the issues we had) that 'Docker Official Python Image' that is part of 'Official Program' [1] is not as 'Official' as I thought so we discuss about changing the base of our images (first CI and then when we see it works fine - PROD) Currently we are using the 'Official' image - but after some issues and discussions with people at PyCon and FOSS Backstage (I had a chance to talk to Python maintainers and even had a few beers with them) - it turned out that the official Python Image' is maintained by 'a community's which really is a few pretty random people - and that explains for example why we have sometimes unpacked security vulnerabilities in setuptools etc. - because they made some compatibility choices and decisions that do not allow them to upgrade easily, also they had some delays in releasing updated Python versions. And Docker does not **really** do much vetting there. So I think it would be good to switch how we build the base for our images. And following the experience of `uv python` [2] - it seems that maybe using "python-standalone" [3] project is a good alternative. It's managed by Astral now (so yes - another dependency on them), but what you have with it you have practically 100% complete Python interpreter installed in seconds. We could continue using debian-slim as a "base, base image" - and install python using "python-standalone". There are a few incompatibilities [4] of the distributions of Python, but there are very few and mostly related to some obscure systems (compatibilities with terminal in REPL, and gtk / UI integration that is anyhow not really working in "standard" Python distributions). I would love to hear what you think - happy to get any feedback/ insights, suggestions and answer additional questions, provide some links to past "troubles" we had with Python "Official" images etc. J. [1] Official Python Images - https://hub.docker.com/_/python [2] UV Python installation - https://docs.astral.sh/uv/guides/install-python/ [3] Python Standalone project - https://github.com/astral-sh/python-build-standalone [4] Python Standalone incompatibilities - https://gregoryszorc.com/docs/python-build-standalone/main/quirks.html ________________________________ Strike Technologies, LLC (“Strike”) is part of the GTS family of companies. Strike is a technology solutions provider, and is not a broker or dealer and does not transact any securities related business directly whatsoever. This communication is the property of Strike and its affiliates, and does not constitute an offer to sell or the solicitation of an offer to buy any security in any jurisdiction. It is intended only for the person to whom it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. Distribution or copying of this communication, or the information contained herein, by anyone other than the intended recipient is prohibited. If you have received this communication in error, please immediately notify Strike at i...@striketechnologies.com, and delete and destroy any copies hereof. ________________________________ CONFIDENTIALITY / PRIVILEGE NOTICE: This transmission and any attachments are intended solely for the addressee. This transmission is covered by the Electronic Communications Privacy Act, 18 U.S.C ''2510-2521. The information contained in this transmission is confidential in nature and protected from further use or disclosure under U.S. Pub. L. 106-102, 113 U.S. Stat. 1338 (1999), and may be subject to attorney-client or other legal privilege. Your use or disclosure of this information for any purpose other than that intended by its transmittal is strictly prohibited, and may subject you to fines and/or penalties under federal and state law. If you are not the intended recipient of this transmission, please DESTROY ALL COPIES RECEIVED and confirm destruction to the sender via return transmittal.
