src.meta.changelog
Description of changes
I'm playing with some ideas inspired by #338301.
What if meta attributes were derived from the source?
In particular, the meta.changelog is a computed value, so having it in the code isn't very valuable as it's not directly accessible.
This also fixed the issue that when src gets overridden, the meta.changelog is out of sync.
Things done
- Built on platform(s)
- [ ] x86_64-linux
- [ ] aarch64-linux
- [ ] x86_64-darwin
- [ ] aarch64-darwin
- For non-Linux: Is sandboxing enabled in
nix.conf? (See Nix manual)- [ ]
sandbox = relaxed - [ ]
sandbox = true
- [ ]
- [ ] Tested, as applicable:
- NixOS test(s) (look inside nixos/tests)
- and/or package tests
- or, for functions and "core" functionality, tests in lib/tests or pkgs/test
- made sure NixOS tests are linked to the relevant packages
- [ ] Tested compilation of all packages that depend on this change using
nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage - [ ] Tested basic functionality of all binary files (usually in
./result/bin/) - 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
- [ ] (Package updates) Added a release notes entry if the change is major or breaking
- [ ] (Module updates) Added a release notes entry if the change is significant
- [ ] (Module addition) Added a release notes entry if adding a new NixOS module
- [ ] Fits CONTRIBUTING.md.
Add a :+1: reaction to pull requests you find important.
I like the idea in principle, but I think we still need to track some information in the package definition, because not all projects use GitHub releases (an in‐repo changelog is usually more useful when available, in fact).
What would be the downside of having false-negative changelog URLs? Package can still override meta.changelog with its definition.
Or alternatively, if the stdenv patch is dropped, packages could opt-in with:
meta = {
inherit (src.meta) changelog;
}
I think exposing broken changelog URLs to users would be kind of bad, but I like the idea of inherit (src.meta) changelog;.
After mulling on this more, even inherit (src.meta) changelog seems too implicit. How would the user know it points to the release unless they read the code?
Maybe a better direction would be a lib that builds common URLs, and maybe used like this:
meta = {
changelog = lib.urls.github.repo_release src;
};
Not a priority so I'm closing this for now
For the spelunkers, see also #35075