I get the impression that Flake files could greatly benefit from the addition of a "version" attribute, not linked to the inputs/outputs, but instead defining the Nix flake schema version.
There are a couple of reasons for this:
- It avoids having to get everything right in version 1 of the schema. Whenever Nix flakes are made stable, there's currently no scope for introducing changes that would break previous implementations without causing significant disruption.
- It makes it easier to have discussions about what should be included in version 1 and what features can wait for later versions. It's better to release something stable that people can use that they can depend on and fully document and understand it's limitations rather than playing around with a moving target.
In my view, this could be implemented in a non-disruptive way. Any Nix flakes that don't have a version attribute can be handled using a "legacy" mode, so it won't be necessary to update every single flake that already exists.
I can imagine some people may question why this is useful considering other configuration file formats doesn't have them. For example, you don't need to specify a version number when working with JSON. That's true, but consider what has been lost by not doing so. For example, JSON has no mechanism for supporting requested features like comments, the only way to evolve is to create a competing format with the desired features. If they had introduced version support before stabilising the format they wouldn't have this problem.
With Nix flakes, while the feature is still experimental, now is the time to introduce schema versions, it'll arguably be too late after the feature is stabilised.
I get the impression that Flake files could greatly benefit from the addition of a "version" attribute, not linked to the inputs/outputs, but instead defining the Nix flake schema version.
There are a couple of reasons for this:
In my view, this could be implemented in a non-disruptive way. Any Nix flakes that don't have a version attribute can be handled using a "legacy" mode, so it won't be necessary to update every single flake that already exists.
I can imagine some people may question why this is useful considering other configuration file formats doesn't have them. For example, you don't need to specify a version number when working with JSON. That's true, but consider what has been lost by not doing so. For example, JSON has no mechanism for supporting requested features like comments, the only way to evolve is to create a competing format with the desired features. If they had introduced version support before stabilising the format they wouldn't have this problem.
With Nix flakes, while the feature is still experimental, now is the time to introduce schema versions, it'll arguably be too late after the feature is stabilised.