Make Nix flakes a first class citizen, fix various issues with modern compilers

[arximboldi]

This PR picks up on the nice work by @alex-sparus adding a flake.nix and integration with Nix flakes. In the process, I've updated nixpkgs and tested with more recent compilers and more variety of systems (this simple trick is so lovely, I love Nix <3). This finally closes #307, sorry it took so long!

I'm kind of late to the party, but after having gotten more experience with Flakes in other places (mostly the NixOS configurations of my private machines and servers) I am convinced that the benefits in reproducibility and dependency management outweight some of the disadvantages (initially esoteric syntax, that flake-utils is kinda needed to deal with systems in a somewhat sane-ish way, etc.). nix develop is just so fast, it deprecates my old hacks I had to deal with nix-shell slowness.

Along the way, I've built some set of opinions that I've implemented in this PR. I hope Alex doesn't get too annoyed:

• I've removed formatting via git hooks. I just find git hooks changing the code a PITA. It sometimes messes things up during interactive rebases. Also it means the git hooks sudenly have dependencies into the nix store and you can't even make a tiny change after, let's say, you nix-collect-garbage. Plus the editors sometimes get confused when the files magically change. I would prefer to add a CI check for the format, to act as a little reminder to set it up on a text editor level, which is where I believe this belongs (there are .dir-locals.el for Emacs users already in the repo).

• nix-shell and nix-build still work, and they do ideally more or less the same as nix develop, nix build. There are situations where I think it's still nice to use them.

  They work via a lightweight nix/flake-compat.nix that I reckon is nicer than having to depend on https://github.com/NixOS/flake-compat (also there are some subtle differences, particularly regarding passing the source files, which I believe are nicer this way).

• I try keep actual derivation definitions outside of flake.nix. The multiple level of nesting (outputs.<system>.packages, etc.) plus the wide surface of the Flake (checks, shells, packages, etc.) make it easily get out of hand and hard to understand. I prefer for it to be just "glue" that uses derivations defined in other files (mostly shell.nix, default.nix and nix/immer.nix itself).

• I have removed a lot of the flake inputs and changed them to manual fetchers. This is my general guideline in this regard:

  • Prefer flakes inputs for the global nixpkgs and for dependencies that are flakes themselves, specially if you need to override inputs (via .follows). Specially stuff that you want to update often and that is used mostly in flake.nix or globally.
  • Prefer direct fetcher in the code for package sources or resources, specially stuff that is not a flake itself, or stuff that is used in a very specific context.

  In this case, the overhead of having to copy the SHA when updating is overshadowed by the benefit of having the definition close to its use. I would say, this is even advantageous friction: e.g. when you update a package source, you need to make sure that the recipe for building it that surrounds it still compiles, and you don't want the thing to be updated carelessly on each flake update.

  Also, this has the advantage that you can copy-paste easily package definitions between projects, instead of having to also copy bits from flake and lock files (or having to re-glue everything together if copying into something that doesn't use flakes). I even apply this rationale for some pinnings of nixpkgs to get very old packages that are used in very specific contexes (e.g. see nix/docs.nix).

Over the next days I'll follow up with similar PR's on zug and lager.

Any objections @alex-sparus, @barracuda156?

[arximboldi]

CIFuzz will pass once this is merged: google/oss-fuzz#14770

[arximboldi]

nvm, just saw they take some time to deal with PR's on oss-fuzz these days so added some backwards compatibility to unblock this

[alex-sparus]

Maybe we don't need that anymore
https://zero-to-nix.com/concepts/flakes/#system-specificity

    # The set of systems to provide outputs for
    allSystems = [ "x86_64-linux" "aarch64-linux" "x86_64-darwin" "aarch64-darwin" ];

    # A function that provides a system-specific Nixpkgs for the desired systems
    forAllSystems = f: nixpkgs.lib.genAttrs allSystems (system: f {
      pkgs = import nixpkgs { inherit system; };
    });
  in {
    packages = forAllSystems ({ pkgs }: {
      default = {
        # Package definition
      };
    });
  };

[arximboldi]

Neat. Yet that puts the burdenn on us on updating the list of systems when nixpkgs updates, I think for now I find depending on flake-utils ok-ish, it seems to be the "de facto" standard... (I wish it was provided by nixpkgs itself to be honest).

[alex-sparus]

so flat_set is no longer supported by boost or what's the status?

[arximboldi]

It is, but there was some weird interaction between its current implementation, GCC, and passing an immer::box to erase() that I couldn't fully figure out, so decided to disable this for now just to move on... it's not a big deal.

[alex-sparus]

What motivated this change?

[arximboldi]

Compilation error on GCC. The T&& argument made the call ambiguous, had to change to const T&, and therefore the forwarding had to go as well.

[alex-sparus]

The changes look good to me. Just a couple questions, otherwise - approved.

[barracuda156]

@arximboldi Been busy with other stuff, but will confirm it works on my end.

[barracuda156]

@arximboldi @alex-sparus Unrelated to this PR, but the build with -Werror still fails, as before: #307 (comment)