| 9 Mar 2025 |
 @ma27:nicht-so.sexy | In reply to @elikoga:matrix.org
People refuse to stabilize flakes because agitators shit and piss themselves about minor design decisions
Flakes cli gets distributed in the nix cli (good)
But remains gated behind a flag (bad)
And since it's not part of nix main the communication around this feature gets incredibly confusing. I believe that the v1.0 semantics of flakes are obviously finished and all the arguments I can see going against this are bad-faith, non-users, agitators, that deliberately misrepresent the technical state so first of all, I strongly disagree that the current issues (flakes being unusable in a monorepo - I still use the old CLI when hacking on nixpkgs; 1000 instances of nixpkgs problem which makes writing flakes with a larger number of inputs pretty painful for me - just to name the two most important issues I have) are actually minor.
the milestone tells me the former thing is somethign the cppnix maintainers also agree. so labelling people as bad-faith agitators if they don't want to stabilize flakes in their current form sounds a bit like an oversimplification tbh. | 14:03:56 |
 elikoga | I'm playing a little bit of devils advocate so let me continue:
The milestone stuff was done following https://github.com/NixOS/rfcs/pull/136 which explicitly outlines as one of it's goals "soothe longstanding tensions"
As it stands, "flakes being unusable in a monorepo" is a phenomenon where the first-order implementation of pure evaluation in flakes (copy source to store) fails to scale properly. I'd love to see more work wrt any workarounds for this (lazy paths) or something like that but I don't care, just use the old interface, which I'm not advocating for depreciation or ripping out.
When it comes to 1000 instances of nixpkgs problem this again reminds me of for example "peerdependencies" of npm. As we can see in the docs: https://docs.npmjs.com/cli/v11/configuring-npm/package-json#peerdependencies , the feature has experienced semantic changes from v2 -> v3 and also from v6 -> v7 to arrive at current day behaviour of npm. I am sure that such iterations are also possible for the nix ecosystem, if only there was any v1 to work with.
| 14:44:04 |
| elikoga | * I'm playing a little bit of devils advocate so let me continue:
The milestone stuff was done following https://github.com/NixOS/rfcs/pull/136 which explicitly outlines as one of it's goals "soothe longstanding tensions"
As it stands, "flakes being unusable in a monorepo" is a phenomenon where the first-order implementation of pure evaluation in flakes (copy source to store) fails to scale properly. I'd love to see more work wrt any workarounds for this (lazy paths) or something like that but I don't care, just use the old interface, which I'm not advocating for deprecation or ripping out.
When it comes to 1000 instances of nixpkgs problem this again reminds me of for example "peerdependencies" of npm. As we can see in the docs: https://docs.npmjs.com/cli/v11/configuring-npm/package-json#peerdependencies , the feature has experienced semantic changes from v2 -> v3 and also from v6 -> v7 to arrive at current day behaviour of npm. I am sure that such iterations are also possible for the nix ecosystem, if only there was any v1 to work with.
| 14:44:42 |
| elikoga | Btw there is no v1 of flakes | 14:44:59 |
| elikoga | Except of course for the release scheme of github:nixos/nix , which is refered to when experiencing incompatibilities from flakes relases. See this example in the wild: https://github.com/nix-community/fenix/issues/129#issuecomment-1841700283 | 14:48:56 |
 emily | is your proposal to remove the experimental flag but be willing to make breaking changes, or to have eternal backwards compatibility layers for old versions? | 14:51:16 |
| elikoga | Pragmatically, whenever appropriate both. There should be a v1 and if we are so inclined a v2 in 10 years or less. | 14:53:23 |
