It appears the Bazel community is getting closer to inventing containers.

You don’t need containers. Just hermetic builds. Ideally every byte read during the compilation process comes from a file under your control, that you version and you test. That includes the compiler, glibc, and all of your dependencies.

Ambient, implicit dependencies are the devil’s playthings.

I don’t think there’s any real insights there.

Containers tend to be coarse-grained. For example, maybe you are writing a program, so you put the entire build environment in a container. If you have lots of programs with different dependencies, do you need lots of containers? Do you need to rebuild lots of containers when dependencies change? Bazel is much more fine-grained, and in Bazel, each individual build action gets its own build environment.

By default, that build environment includes the host (build system) glibc, compiler, system headers, system libraries, etc. If you want repeatable builds, you turn that off, and give Bazel the exact glibc, compiler, libraries, etc. to use for building your program.

You get the isolation of containers, but much faster builds and better caching.

Bazel comes with ironclad sandboxing features, but people don't use them because build correctness is such a chore.

Bazel has number of strategies, including containers.

But that’s only a minority of what it does.