Coming from a more programming language and less package management background, I have a different biases on compatibility to nix. However with flakes exporting library symbols, this all feels very similar, and we seem to be entering a world where diamond dependencies once again become a problem.
On the performance side, while this seems to come out of a desire for perfect compatibility and reproducibility and solves diamond dependency problems for shared libraries and binaries, it means that we have a 1000 instances of nixpkgs and complaints about “why am I compiling four different rust compilers just to get one python package”.
Finally, it would be nice to have a single way of signalling to users (and
nix flake update) that they can I safely upgrade a flake. Currently, some have chosen semver, others seasonal incompatible releases, and others rolling releases.
One potential solutions follows:
First, we would need to agree on a way to expose a flake version string, say
Next we can choose to define semantics for what it means. I have a strong preference for “just do semver”, it has flaws, but is quite powerful. Alternatively, we could simply do a string compare, and request that users change the value when compatibility is broken, similar to what
Finally, we could introduce a new flag for “I want the latest version of every compatible version of a given flake”. (I am assuming vcs could be used to define what “latest” is.) This would effectively be syntax sugar for
builtins.mapAttrs (_: input: input.inputs.yyy.follows = yyy) inputs for all compatible versions of
In semver terms, this would mean you would only need one input for every major version, or in nixpkgs terms one input for every seasonal release.
Note, since this breaks reproducibility guarantees just like
inputs.follows, it could cause two working flake inputs to break their parent. Fortunately, this will only result from a bug or broken compatibility promise, and most other languages have decided that version ranges [recte sat solvers] or just pushing the upstream author to fix the bug, are good enough. However, since this changes the user experience, I can understand that this may be too critical a promise to walk back, even if it saves a few GB of
/nix/store or hours of compile time.