Changelog with variables

Development Nixpkgs Architecture
1

I was wondering why something like the following meta definition isn’t allowed:

    meta.changelog = "https://github.com/${finalAttrs.src.owner}/${finalAttrs.src.repo}/releases/tag/${finalAttrs.src.tag}";

This could even be automatically populated if the src attribute has its tag attribute populated. What is your opinion on this?

2

It’s very verbose/cumbersome to read, pays an eval-time string interp cost, and breaks the URL if src is overwritten.

1 Like
3

Only if src is not still a pointer to the GitHub repository. And if that’s the case, the original meta.changelog is probably no longer applicable.

4

Probably because meta.changelog is probably the most useless field in meta, IMO. (Basically nothing consumes or displays it, that I know of.)

5

The Nixpkgs update bot does (example)

3 Likes
6

Sure. but I hope we can both agree that breaking eval is bad.

7

We’re talking about a consumer who overrides src on a package and then also consumes meta.changelog on that package (if you don’t explicitly consume it, nothing breaks), and the choices are between an incorrect value and an error. I’d argue the error is preferable, though it’s a niche enough scenario that I don’t think anyone should care strongly either way.

1 Like
8

Additionally, many reviewers like to click on the link. If it’s parameterized that does not work.

2 Likes
9

I’m skeptical about the wisdom of this, but I could get behind adding a passthru.releaseUrl attribute to fetchFromGitHub (and other forge fetchers, as needed), and then packagers could write meta.changelog = finalAttrs.src.releaseUrl; if they don’t have a better changelog to which to link, similar to how meta.homepage is often inherited from src.

1 Like