 | Nix Flakes | 877 Members |
| 180 Servers |
| Nix Flakes | 877 Members |
| 180 Servers |
| Sender | Message | Time |
|---|---|---|
| 9 Mar 2025 | ||
 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 |
| elikoga | But if you want to add to add the attribute "lastModified" to tarball inputs then it's a breaking change for some and you should add backwards compatibility since It's not deserving of being a format-bump Just as has already happened in github:nixos/nix as far as I can see | 14:54:57 |
| emily | ok. I think you underestimate the burden and headaches of supporting e.g. the exact current weird/busted fetchTree semantics for all of eternity (indeed there have been recent bugs where the fixes would have been considered potentially unacceptable compatibility breaks for stable Nix already iirc). flakes are not nearly as simple under the hood as they appear on the surface | 14:55:50 |
| elikoga | Links would be lovely | 14:56:30 |
| emily | I don't think it's a conspiracy that almost everyone who works on a Nix-derived codebase thinks that stabilizing flakes is a very complicated process | 14:56:35 |
| emily | and I do use flakes. but anyway, you can consider me an agitator deliberately misrepresenting the technical state if you wish | 14:57:03 |
| emily | https://github.com/nix-community/fetchTree-spec didn't get off the ground yet but involved people from three separate Nix implementations and there's some documentation of very weird behaviour in the issue tracker. most of this stuff is just scattered across a dozen issue reports and PRs though. | 14:59:58 |
| emily | also roberth already gave a good example: | 15:00:17 |
| emily | "As a brief example, we’ve had a case recently where users were using flake inputs to fetch submodules. This is completely unnecessary since 2.26, and it only worked for them because their working directory happened to coincide with the flake root. Sensitivity to the working directory instead of base directory is bug, so here you see an interaction between the two kinds of stability that we discussed. If we had committed to the 2.25 behavior of flakes by blessing it as stable, we would have to implement a completely unnecessary feature which would even require some architectural changes, removing the separation between fetchTree and the base directory concept, forever making call-flake.nix and the native code that interacts with it more complicated." | 15:00:25 |
| emily | flakes have reliably had more breaking changes than any other part of the language really | 15:01:14 |
| emily | lots of weird stuff around subflakes too | 15:01:30 |
 WeetHet | In reply to @elikoga:matrix.orgTbf one could argue it became this way due to widespread propaganda of flakes as an entry point into the nix world which they imho shouldn't be | 15:17:50 |
| elikoga | What the fuck else should I be using to lock my lockfile? npins? Pinning by hand? | 15:21:01 |
| elikoga | Should I set NIX_PATH myself like a Victorian era peasant? | 15:21:37 |
| elikoga | Should I write my own script to do the fetching? | 15:21:51 |
| elikoga | What is the path of least resistance to getting a lock file? Using the built in lock file management. I must admit, the shilling can go on my nerves too, but as far as I can tell, that's why there is a low lack of understanding accross the entire nix ecosystem. Getting users acquainted with configuration.nix first may be very easy but it can lead to a large population of users unfamiliar with what they are doing | 15:24:53 |
 hexa joined the room. | 15:26:44 | |
| elikoga | * What is the path of least resistance to getting a lock file? Using the built in lock file management. I must admit, the shilling can go on my nerves too, but as far as I can tell, that's why there is a lack of understanding accross the entire nix ecosystem. Getting users acquainted with configuration.nix first may be very easy but it can lead to a large population of users unfamiliar with what they are doing | 15:27:41 |
| elikoga | I am sorry for my crass language yet the other side can call the feature "a stain" on the language I am allowed to swear a little bit when complaining about a lack of solutions given | 15:29:53 |
| emily | I think it's not productive to discuss this further unless you want to retract "all the arguments I can see going against this are bad-faith, non-users, agitators, that deliberately misrepresent the technical state", which seems to have been based more on your own ignorance of the technical state than mine | 15:33:26 |
| emily | I haven't participated in any mud-slinging myself, so I don't think you have any reason to be like this when I'm trying to engage against my better judgement | 15:34:03 |
| hexa | https://discourse.nixos.org/t/experimental-does-not-mean-unstable-detsyss-perspective-on-nix-flakes/32703/2 is another post that summarizes existing issues with flakes | 15:37:33 |
| elikoga |
Actually this smells like the collusion and intimidation I know from university politics. This post has been quoted many times, yet I believe that all of the points are not release-blockers and deliberately use emotional language like "is awful and a clear downgrade from stable Nix." while not considering any of the technical tradeoffs I think I'll write up something longer and much more calmer on this in a bit or defer that to the future since I don't see going around in small messages going anywhere. Thank you all for taking the time to discuss | 15:42:06 |
| emily | I literally gave a link and a quote when you asked? | 15:43:20 |
| emily | I spent several minutes digging them up for you, even though the quote was from a forum thread you've already been participating in… | 15:43:53 |
| emily | "collusion and intimidation" – I am speaking entirely for myself and have not participated in any of these forum threads | 15:44:16 |