No, Eelco doesn’t have that authority
That might be the case today, but let’s not forget that this was clearly not the case when flakes were designed, initially merged into master, introduced everywhere despite an ongoing (and then closed) RFC.
I want to address three common criticisms of flakes.
No mention of lazy trees? oO
I think there was pretty much a consensus that this was the main issue to be addressed before dropping the experimental flag. Because flakes are absolutely unusable in large repos (I tried nix build .#hello
on a dirty repo - i.e. a normal situation when working on nixpkgs and I decided that I’ll never do that again. Also the reason why I’d never sneak a flake.nix
into a monorepo).
This PR completely exploded, started suffering from feature creep and… stalled. In fact it was pretty usable (to me at least, though I’m despite my criticism here a flake proponent and use them pretty heavily, so I considered that a good sign) at some point in winter last year until I got some weird breakage on each update and I had enough. Even worse, lazy-trees is the reason to revert other valid bugfixes that are… still bugs, e.g. Revert "Merge pull request #6621 from Kha/nested-follows" by edolstra · Pull Request #6983 · NixOS/nix · GitHub.
I mean, complaining about another NixCon without a clear way forward while there was a plan last year is… questionable to say the least.
But it has nothing to do with flakes and thus no bearing on stabilization.
Right now we depend on a single system attribute in several outputs (e.g. apps/packages) and the output discovery expands e.g. .#foo
to .#packages.<builtins.currentSystem>.foo
in nix build
(briefly said).
This means that we have something that juggles around with a system field without taking cross-compilation into account at all while we skip the entire problem with the nix-*
commands. Yes, that may or may not be pretty either, but with a design actively neglecting this, I don’t think it’ll be easier.
Also, this is nothing new: [WIP] Add 'perSystem' and 'systems' schema attributes by gytis-ivaskevicius · Pull Request #6773 · NixOS/nix · GitHub & Provide builtins.currentSystem as a input to flakes or make system a parameter · Issue #3843 · NixOS/nix · GitHub.
It’s a good read but I disagree with the conclusions. With evaluation caching and the functional nature of Nixpkgs, source explosion is generally mitigated using the follows mechanism built into flakes, which reduces the number of unique Nixpkgs instances involved in an evaluation.
I think the main point is the usage of import inputs.nixpkgs
in each flake which will cause a massive amount of evaluated nixpkgs
(and follows
doesn’t work recursively, the fix was as mentioned rejected because it was too hard to mege against lazy-trees).
Also, evaluation-caching doesn’t help at all when working with the code because this cache (IIRC) only caches top-level drvs and not “intermediate” drvs in the dependency-tree, so everything will be re-evaluated in a dirty tree with fresh changes.
What you can do is e.g. builtins.foldl (nixpkgs: nixpkgs.extend) (nixpkgs.legacyPackages.${system}) [ overlay1 overlay2 overlay3 ]
to use a single instantiated nixpkgs if follows
is applied carefully everywhere (i.e. each flake passes a follows
down to its subflakes properly). However you can’t configure nixpkgs
that way (i.e. allowUnfreePredicate
etc.).
prior to stabilization, as a new mechanism can increment the flake.lock version field.
At least I agree with that ![:wink: :wink:](https://discourse.nixos.org/images/emoji/twitter/wink.png?v=12)
See the difference to the other issues? This is something we can easily change without severe breaking changes.
I gotta say I’m rather surprised by this article. While I think we’re somewhat on the same page, i.e. I also think that flakes are a massive improvement for a lot of people (myself included - that’s why I’m using them since 2020 and have also contributed numerous fixes to it), I think that the core concerns about the current state are misrepresented in this article.
When I’ve read it first it seemed to me as if the the main message was that the only arguments from the community are shallow and only there because people dislike flakes in general. While I don’t think that this was the intention, that was my first impression. And I’m concerned that such prominent statements will only worsen the divide we’re already battling in the community.