Angle brackets in a Nix flake world

Links
1
11 Likes
2

Nice write up, the use of the angle bracket syntax is interesting. Though i think i disagree that adding buitins.currentFlake would be pure. It’s also very very hard to define, when it should switch a flake input of the toplevel flake. So I’m not sure such a chabge would be a net positive

3

This is quite interesting indeed, but why don’t you use self instead of getFlake?

flake.nix 
{
  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
    nixpkgslib.url = "github:nix-community/nixpkgs.lib";
  };
  description = "Trivial flake that returns a string for eval";

  outputs =
    {
      nixpkgslib,
      nixpkgs,
      self,
    }:
    {
      __findFile =
        nixPath: name:
        let
          lib = nixpkgslib.lib;
        in
        lib.getAttrFromPath (lib.splitString "." name) self;

      hello = "Hello from a flake!";
      example = builtins.scopedImport self ./default.nix;
    };
}
default.nix 
<outputs.hello> + " and welcome to Nix!"

$ nix eval .#example
"Hello from a flake! and welcome to Nix!"
2 Likes
4

Thank you that’s great.
Originally I had the lookup in a different file before I discovered scopedImport

I’ll update the example with this :pinched_fingers::ok_hand:

1 Like
5

While I appreciate the concept of new angle bracket syntax, I don’t think the Nix language needs flake-specific syntax. Flakes have been adopted by the majority of the community - but NIX_PATH was previously adopted by the majority of the community. The shortcomings of flakes are well-documented, and they are still experimental for established reasons. Even the biggest proponents of Flake stabilization acknowledge that future iterations on Flakes will happen, and plan on supporting them.

I don’t think entrenching ourselves further in flakeland is the right move. I’d prefer to see angle brackets used for something more meaningful, like providing a module system with faster evaluation.

5 Likes
6

as always another cool article from @fzakaria :sunglasses:

personally i prefer a simplified __findFile like this:

__findFile = nixPath: name: inputs.${name};

that is… map each flake input, but not output
my reasoning is that this is a more natural progression from channels to flakes and keeps the same semantics - flake inputs are an extension/improvement/natural progression of channels

but then again… i don’t like most flake outputs, so i guess i have a bias there… :sweat_smile:

3 Likes
7

Thanks for the kind words.

The problem with ${name} is that if you do “a.b” it puts it as a single attribute quoted. I guess for inputs it may not matter.

Why support output?
Well I want to access my own packages or modules sometimes instead of through an overlay

8

I just pushed an update to the blog with your improvement – thank you.

2 Likes
9

The ability to use angle brackets is very interesting, though scopedImport has huge performance penalty (iirc it disables memoisation). Some testing with nix-instantiate (I don’t use flake but npins) shows that the evaluation time goes from 17 seconds to almost 30 seconds, doubling the evaluation time…

1 Like