| 9 Mar 2025 |
 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 |
