Conversation
This opens the road to removing a lot of the repetition we see in the meta attributes. Most of the time, computed values such as the changelog URL are already known from the source fetcher.
Assume that the changelog is attached to the release.
github-actions
bot
added
6.topic: fetch
|
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 Or alternatively, if the stdenv patch is dropped, packages could opt-in with: |
|
I think exposing broken changelog URLs to users would be kind of bad, but I like the idea of |
|
After mulling on this more, even Maybe a better direction would be a lib that builds common URLs, and maybe used like this: Not a priority so I'm closing this for now |
|
For the spelunkers, see also #35075 |
2 participants
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.changelogis 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
srcgets overridden, themeta.changelogis out of sync.Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.