I understood why it was done, it just happens to break my (not-so-standard) usecase
If by that you understand having to add --override-flake each and every time, I’m not sure it’s any better (and I get how I can force it to use local package, not local registry). Adding it on every nix flake update might be acceptable (though still more work than previously). I might play a bit with --inputs-from and/or --reference-lock-file, the descriptions looks promising as well.
I don’t think your usecase is uncommon. I also used the local registry to ensure the nixpkgs versions were the same as on my system and avoid unnecessary wasted downloads and disk storage. Those were mostly personal projects without other contributors and I do think that is a valid usecase.
Yes, this is how open-source works. You’re welcome and free to help, but since this is on voluntary basis, you should not expect things and wait a bit.
Add a flake input referring to upstream, and use the package from that flake in nix.package.
Of course I can’t recommend this, since if nix breaks, your whole system becomes (temporarily) unusable, and if that version of nix is not in nixpkgs, then the appropriate tests have not been run on it.
If you still have questions on how to use flakes, create a new topic.
I just noticed that nixVersions.latest is set to nix 2.25 in unstable even though there is a nixVersions.nix_2_26 attribute. Also FWIW I noticed that Nix reference manual — nix.dev documentation still lists 2.25 as the latest. Anyone know why?
Last time I tried to bump the Nix release the upstream Nix 2.26 derivation didn’t have a doc output, and I currently don’t have capacity to keep track of that. @roberth does it happen to have been fixed already so I can run the update script again?
