One flake to rule them all
9 points by PieWombat
9 points by PieWombat
Some guys will do anything but drop flakes (even if labeled as “meh”).
The core issue is default behavior, transitive dependency pull in, has very nasty side effects & follows can only partially fix it while not having good ergonomics even when it does work. If instead your project makes everything in Nix importable or callPackageable, you no longer have the same issues—& now your code is more composable, more overrideable, + more importantly: simpler, using mechanism Nix has had for the last 20 years. follows only offers the ability to align your deps, not modifying the nodes in the graph of pkgs (via overlays) or modules (via import = [ … ]).
On modularity, note there is no mention of system for overlays since it just describes modifying the pkgs graph—flakes tend to push folks ergonomically in the direction of defining packages.${system}.${…} instead of putting it all packages in the overlay to be re-exported them as packages (or worse, coupling your packages to something like flake-parts). You can grep for the word self in your code to get a hint for coupled code (not including makeScope or overlays making self the arbitrary argument name). This is why often times things only tend to work inside of flakes & require that extra evaluation step. I think hiding the complexity behind this cron job on a platform with bad uptime (& no mirrors) isn’t a solution to the lack of modularity we could/should have as Nix users from Nix projects. You do want to be explicit about imports… it’s that flake ergonomics + default behaviors aren’t good.
Instead, I would rather see less trying to code around flake design problems & more efforts to uncouple upstreams so follows + dependency count/size issue becomes irrelevant since the code would be stable-Nix-compatible since it seems the stable Nix pinning options don’t even have lock explosion problems (it would even let downstream users opt out of experimental flakes, while still being compatible to those that wish to live on that edge)—especially at even any level of scale beyond a workstation, as dev tooling + circular dependencies make the JSON lock skyrocket in size (I even heard an anecdote recently of a team using Git LFS just to handle the size of the flake lock). Ironically the other way to deal with this issue in flakes is to set all inputs to flake = false which just returns a store path like other input pinners, just with more code, less features, & diverging flake “standards” in Nix, Lix, & Dix that lead to instability.
Happy to collaborate on ideas. I like building.
That’s a part of the problem tho. I think flakes offer a “meh” experience in terms of general, day-to-day UX improvements to your average user, but I don’t think the foundations flakes are built on should be anything we build on or try to hide its flaws if we start from the premise that the foundation we build on is wrong—to which something the most experienced Nix users tend to agree with. I think building less would be better, but raising stable Nix pattern awareness is a better route for the long-term—where experimental flakes should be labeled “experiment failed” given how deadlocked, buggy, & full of holes it is… at least not as something built into the compiler/binary.
I meant collaborate on anything fwiw; I get it -- you don't like flakes. Let's build other stuff :)