I’ve only been using NixOS for the last month or two, but I’ve gotten to the point where I’m relatively comfortable. I’ve migrated dotfiles, I have my machine built the way I want (doing things I hadn’t managed before NixOS, and it’s fantastic!).
There’s one part that I haven’t yet managed to get into place, and that is development environments. I’m used to using tools like pyenv and goenv to manage per-project configs, and so I’ve settled on direnv, and I’m using lorri to make that process a bit more efficient.
Where I’m running into problems, however, is supporting the build systems of the projects I work on. I can’t make everyone else migrate to NixOS, so I have to find ways of enabling my system to behave closer to how other linux systems work.
My main problem at this point, however, is building software with bazel. For those who don’t know, bazel attempts to bootstrap its build tools, to make it independent of the surrounding environment. It fails to be hermetic, however, because some of the most common build rules (e.g. go) download binaries that depend on the outer environment.
So far, I’ve run into two problems, the first is with binaries (like protoc) which depend upon libstdc++ and the second is the go binary, which seems to have incompatible linking.
For the first, I created a direnv where I update LD_LIBRARY_PATH to include stdenv.cc.cc.lib/lib, which allows protoc to run.
For the second, there’s a way to tell bazel to use the host go toolchain instead of downloading, which works.
So far, so good, but sometimes bazel runs programs inside of a sandbox (using the
linux-sandbox binary), and now my carefully crafted LD_LIBRARY_PATH is lost, and protoc fails to execute again.
When I add a package to environmentPackages, it is symlinked into my environment. Is there a way to symlink stdenv.cc.cc.lib into my environment so that I can successfully build using bazel despite the linux-sandbox command? (I know, ironic name, since it’s not a fully functioning sandbox)