Wow, I tried NixOS at one point but I couldn’t keep it as a daily driver because it didn’t play nicely with my conda-based dev environment.

I’m not familiar with it but it looks like conda heavily relies on prebuilt non-static binaries as well… which do cause issues the further the target system is from the system that built it (and NixOS is very far away from most Linux systems). Another reason why I don’t like providing those anywhere unless they’re statically linked, I guess :P

However it looks like conda in nixpkgs is packaged with an additional conda-shell script which drops you into a shell with the expected library paths so stuff should work, if you want to try it again. There’s a small section about it in the NixOS Wiki. (The same workaround also exists with a lot of other prebuilt binaries that expect FHS paths, steam-run being a convenient wrapper for that which makes most stuff just work. It uses the Steam runtime, that’s why it’s called that, but it works for anything, not just games.)

I knew nix like guix (another failed experiment I wanted to make my daily driver) could be run as a package manager but I had no idea it could cross-compile and copy in one command!

Yup, that’s pretty much the result of a lot of work in nixpkgs done to make cross-compilation for various compilers work well without having to explicitly support it in each package, and especially without having to package cross-compiled stuff separately. So if you write a remotely standard Nix package for some software and it builds normally, chances are you’ll be able to cross-compile it without any further work on your part. Nixpkgs also automatically exposes these cross-compiled packages for you under the pkgsCross attribute set, which contains the exact same packages as top-level nixpkgs but with a different build host target, so for packages inside nixpkgs you don’t even have to instantiate it with custom options to set up cross-compilation.

And nix copy will then simply build the package you specify if it’s not already in the local store or the build cache before sending it to the target host. You can also do the reverse, specify one or more build hosts (that are more powerful, or have a different architecture that a package needs) so that nix will do distributed builds on those other hosts and then automatically copy the result back.

I did try Guix as well because Scheme seems very cool and it hasn’t accumulated as much tech debt as NixOS and a couple better designs from what I’ve seen (for example grafts), but failed at the lack of proprietary software (:

These are static builds right?

Unfortunately not, I tried statically building it but it seems at the very least PostgreSQL which is a dependency fails to build that way (there’s an open issue here). I guess a lot of software simply isn’t tested for static building because it’s usually a giant pain to do, since you need each transitive dependency built as a static library to end up with a static binary in the end.

But Nix binaries are linked in a way that they will load exactly the shared libraries they were built against by their store path (in most cases), so effectively it should behave the same and never load incompatible libraries. It just means you can’t copy it around and need to leave it in the store.