On investigating buildpacks a bit in pockets of spare time, one of the simplest ways to start using them to promote understanding within the team and better handle user requests in Toolforge would be to begin the process of replacing the management of docker images for Toolforge Kubernetes with buildpack-generated images.

This would basically look like taking the python3.7-sssd image (for instance) and dropping it from toollabs-docker-images while establishing the buildpack for it, along with appropriate scripts to simplify rebuilds of the pack.

This generally would introduce the complexity of having a second script to run to rebuild docker images, but that would only be true until all legacy images are now buildpacks. Besides that, this would make eventually migrating to CD-controlled buildpacks vastly simpler.

This is expressly not introducing the functionality of pack to Toolforge to dynamically generate the image based on the buildpacks because that needs to happen in a closed-loop environment like CD. This is simply about changing tooling around images to one that is a bit more flexible and potentially a lot less "OS-based" since buildpack-inspired processes like the official Python images on Docker hub and buildpack stacks in general, usually start from a tar file of the runtime built by the builder rather than OS packages.