I’m doing lots of (poorly) automated hash updates, and I’m encountering issues - where it’s not always possible to figure out where a given file is referenced. Does anyone have advice (Ideally a nix query), that can figure out how to map a derivation defined in a given file to an attribute to build? (attributes → files is also valuable since I can reverse it).
Right now I have a couple patterns, then an overrides map and some heuristics, which is nice, but not the best.
Attribute → file mapping can be obtained using attr.meta.position (or setting EDITOR=echo environment variable and running nix editcommand).
The other way around is not really a thing at the moment, I just hardcode the attribute paths in the update script:
There are some ways around it but generally they will not be very efficient. @Infinisil chatted about it recently
#nixos-dev on 2020-05-06 — irc logs;
I’m doing lots of (poorly) automated hash updates, and I’m encountering issues - where it’s not always possible to figure out where a given file is referenced. Does anyone have advice (Ideally a nix query), that can figure out how to map a derivation defined in a given file to an attribute to build? (attributes → files is also valuable since I can reverse it).
For attribute → files I would consider strace-ing the evaluation process. Asking Nix where the package is defined won’t show you the patches… and then there are some complicated multi-layer packages where one file defines the function and the other chooses the arguments.
I guess eval-release (see in nixpkgs/maintainers) is a natural thing to strace if you want to see what is referenced by any Hydra builds. There are, of course, some packages that seem to have some users but are not referenced by anything that has an attribute name (I think we have some popular overrides), in case of Chromium that might mean patches that are usable but unreachable in the attribute-enumeration way.