flake.nix: init

[philiptaron]

I like flakes. 🤷🏻‍♂️

• Added flake.nix
  • Wired up the package to the default build output for nix build
  • Wired up the shell to the default shell for nix shell
  • Wired up the two checks (for formatting and nixpkgs) to nix flake check.
  • Added the hydra-built systems as the default systems
• Added nix flake update to the update scripts
• Reshaped default.nix to accept pkgs as an input
• Added treefmtWrapper (per the docs on treefmt-nix) that fits into nix fmt.

[infinisil]

I'm not against having a flake.nix in principle, but this currently duplicates all the input locking! And I'd rather not use flake inputs because then they can't be overridden by stable Nix (unless you implement it manually).

So flake.nix should just be a tiny layer above default.nix, like the one in nixfmt.

[philiptaron]

@infinisil, it is a tiny layer above default.nix! I did it differently than the nixfmt one because the Nix code is shaped differently, but there's no getting around the flake's use of flake.lock. I thought the simplest way to go was duplication rather than trying to make npins flake compatible.

That said, npins does support importing from flake.lock as of a few days ago.

[infinisil]

there's no getting around the flake's use of flake.lock

There is though! If you just don't specify any flake inputs and instead import the default.nix (which then uses the niv-pinned ones) with its default arguments, it should work just fine

[philiptaron]

if you don't specify flake inputs

But that's what I want the flake for -- specifying inputs. Without any inputs, as a flake consumer, I have to use whatever's pinned, and there's no ability to override.

I think the right way to go is to update npins to 0.2.4 (per the linked review), then use the import-flake to base the npins off flake.lock.

[willbush]

Would .envrc be use flake or use nix?

[philiptaron]

Would .envrc be use flake or use nix?

It would be able to contain use flake should this PR be merged.

[infinisil]

Without any inputs, as a flake consumer, I have to use whatever's pinned, and there's no ability to override.

You can override the pinned sources using the default.nix. E.g.

{
  inputs.ncbn.url = "github:NixOS/nixpkgs-check-by-name";
  inputs.ncbn.flake = false;

  outputs = { ncbn, ... }:
    let
      result = import ncbn {
        nixpkgs = <something else>;
      };
    in
    {
      packages.ncbn = result.build;
    };
}

This notably has the advantage that you can even override it with a version of Nixpkgs that Flake inputs can't represent, e.g. one patched via a derivation, or fetched with a non-builtin fetcher, etc.

[willbush]

Feel like I don't know enough about the pros/cons of flakes despite using them for like 4 years.

I think at a minimum we shouldn't have two lock files for the same inputs.

Is there any tradeoff in evaluation caching between using flakes vs npins lock file?

I was trying to brush up a bit on arguments against flakes reading this, and read this:

There are several tools that can maintain a lock file with Nix hashes, such as Niv, npins, and gridlock. The first two sadly ship Nix files that use built-in fetchers and thus have the evaluation performance issues

emphasis mine. No idea if that's true or out-of-date.

[philiptaron]

I'm returning to this PR after a couple weeks, but I'm going to be experimenting with how GitHub actions runs the code a bit so please bear it no mind until it's out of draft.

[willbush]

Would .envrc be use flake or use nix?

It would be able to contain use flake should this PR be merged.

I noticed this recently use flake || use nix.