Fetchurl (or similar) as a way of getting an alert if something changes upstream

I find myself having to sometimes extract code directly from nixpkgs and then altering it slightly to suit my needs. In these cases I’d like to have a way to get an alert (probably via trace or assert) of some kind when new commits/changes are introduced to the file where I extracted the code from to check for updates and possible conflicts.

Something like fetchurl with the hash field set to the last “I’ve checked upstream” value would work, but nix seems to only download the source again if I intentionally change the hash, which is the one thing I’d like to keep as a reference.

I feel I may be overreaching what nix alone is meant to do, but essentially a solution that checks “once a week”/“when I update my inputs” would be ideal.

Copying code directly as you do now works for hacks, especially if you still struggle with the language, but the downside is precisely what you’re running into now, you’ll to struggle updating.

Rather than hacking around with fetchurl, I’d suggest one of two workflows:

  1. Use override and overrideAttrs
  • For modules, just write to the options directly
  1. Maintain a fork of nixpkgs

The former works well for truly little changes, like modifying a src or adding an additional compilation flag or such. In those cases, you typically want to keep your downstream modification permanently (or until you want to change it), so updating the modification itself is only necessary if it becomes incompatible with the rest of the build - in which case it will fail to build and you will thereby be notified of the change.

The latter is better for wider changes, or just if you really have a lot of them. In that case, you just rebase to the latest version of nixpkgs once a week (or whenever you usually update). Git will then tell you exactly what - if anything - changed about the files you modified. Git is literally designed to manage updates like this (and in fact kind of does what you describe), let it do its job!

I’m pretty comfortable with the language, the request was mostly aimed at seeing if I could make a convenience alert that would pop up every now and then while rebuilding without much input elsewhere from me when doing something like:

(In this case I was trying to avoid the hardcoded choice of amdgpu for a prime related option which I guess I can just patch, though not without it’s own complications)

Did consider keeping a fork of nixpkgs, though I was looking for a way to sidestep that.

What do you mean by

For modules, just write to the options directly

1 Like

Just, instead of .override/Attrs, when you need to change something in a module, just writing directly to the options it recursively uses, since there’s no sensible way to override modules without disabling the whole thing.

But yeah, I think a fork is the most sustainable solution to this problem. As a bonus, this makes it easier to upstream things when you eventually think it’s useful to do so.