Three points to make about this OOT Docker example.
1) Everything you're doing manually here can be accomplished using pybombs2... and pybombs2 makes itself quite amenable to existing within the Docker image both as an interface to what's already installed on the image and a handy way to install new OOTs and dependencies on top of the image. I would favor using pybombs2 as a basis for gnuradio Docker images... at least that's what I'm doing for myself.
2) Supporting a pybombs2 Docker image is a great way to ensure that pybombs2 builds from a very, very minimal initial Linux installation. Since pybombs2 is newish and experiencing lots of activity, the project might benefit from anchoring itself to nightly Docker builds.
3) How to handle OOTs could be a bit more complicated if you try, as I have, to reduce image size using the pybombs2 "deploy" mechanism. Deploy lets you do two nice things... it optionally strips all the src out of your build automatically (a significant weight reduction step, as you note, but installed .h files remain... sort of like a dev package). It also compresses the rest of your build. As long as you install and then compress in the same Docker RUN call, your UFS layer is small, too. The result saves GBs over the wire (I think?). When you're using Docker to deploy code, image sizes over the wire can be a big deal, and I'd love for it to be convenient enough to start each day off by docker pulling the latest build. The "pybombs" image I posted is a vanilla pybombs2 install with uhd forcebuilt and the source stripped (so it's pretty much a complete gnuradio build, gui and all)... it's ~1.5G to download (Again, I think? Sometimes you have hidden image layers that make things appear smaller than they actually are.) That's big in Docker world from what I've seen, but it's not much of an inconvenience. ~2.5G for the version retaining the source code is a little more glaringly bad. Fortunately, unless you're working on code in the uhd or gnuradio repos, the 1.5G version is totally fine.
For me, these are the "natural" GR versions to support via Docker... I'd be interested in a version more like yours that strips the gui and other modules, too. Maybe it's worth cutting uhd in an image, but 200MB doesn't sound worthwhile at that cost.
I'm interested in experiences/opinions regarding the use of pybombs deploy to compress between intermediate UFS layers. Am I somehow overestimating the savings in image size? Does it seem too complicated, and/or am I overlooking an easier way? Maybe no one cares about image size? (Actually, I know some people who definitely do care, or at least they claim to care. I'm pretty sure I will, too.)
I don't think building the distribution in explicit layers is very helpful. It's something that seems useful when you hear a description of the UFS, but it seems to wind up being a waste of time. One or several GR images makes sense as a basis for images building OOTs, but what the hell are you going to do with an image that's run pybombs install boost except run pybombs install gnuradio?
Cheers,
Nick M.