Nix 2.4, and what’s next?

[pxc]

@samueldr

Also note previous grievances about the nix command-line being changed beyond recognition in the name of Flakes.

As I think has been outlined in some of the responses, it might be more accurate to say that flake.nix has been designed to accommodate a smarter Nix CLI, by defining a schema for the kind of metadata it takes to support a smarter CLI. (It’s probably fair to say that this has involved some entanglement, as flakes and the new CLI have been designed together.)

@thufschmitt emphasized this here:

@thufschmitt

Flakes are not really a thing by themselves. They only make sense as part of a global cohesive interface.
The design of the CLI is indeed tied to flakes, but the design of flakes is also tied to the constraints of the CLI.

I think that if we think of flakes essentially as metadata designed to support (1) pure evaluation and (2) a better CLI, it becomes much easier to motivate flakes.

Because I think the discussion in this thread is intended to be more focused on process issues that are not necessarily specific to flakes and its implementation, I’ve split the elaboration of this thought into a separate thread. (Mods, feel free to merge it if putting it in a separate thread takes up too much space.)

I don’t think what I have in mind is especially novel or non-obvious, but I do think it’s potentially relevant and I’d be grateful for any thoughts on it, especially from regular Nix contributors and the signatories of the OP.