But why is it "gross"? I'd have thought it would be especially useful in C development where headers and other development packages are typically installed globally on a machine - it would allow you to have multiple isolated environments, the correct packages (and versions) in each of those environments, and your editor/LSP/IDE would be able to interact with that isolated environment pretty much out of the box.
I don't really see the difference between just building via docker, and doing static analysis, incremental builds, running tests, etc inside docker. Surely the goal in all these scenarios is the same: a reproducible environment for every developer on the project?
There's a higher friction to working with that isolated environment.
It's hard to take stuff out of a running container; and it's hard to access files/programs on the host from within the container.
There may be advantages to running inside a container; but it largely feels like when there are easier ways for quickly making programs available to the host (e.g. virtual environments, or asdf version manager), then most tools aim for that first.
Honest question.. have you used dev containers? Because these seem like solved problems.
Bind mounts let you easily move files in/out of the container (and are already set up by devcontainers). And the whole point is to _not_ access programs on the host, you want that isolation so that the environment is reproducible and everything you need to build is defined in the dev container.
It just needs your build toolchain and libs.. you don't need to use the shell from the container to run random unix utils or curl for instance.
I don't really see the difference between just building via docker, and doing static analysis, incremental builds, running tests, etc inside docker. Surely the goal in all these scenarios is the same: a reproducible environment for every developer on the project?