`unsafeGetAttrPos` returns incorrect positions after overriding

[xaltsc]

Describe the bug

Some packages define derivation attributes using arguments provided to them (typically when using pkgs.callPackage).

When overriding a package, nix seems unaware that, somehow, the location of attributes (or rather, their values) have changed.

This may be expected behaviour and not a bug conceptually, but is very much one practically.

For instance https://github.com/Mic92/nix-update/ uses this and guesses wrongly.

Steps To Reproduce

This, by far, not a minimal example, but it's the one I have at hand. Consider the following package, located at the file new-cef-binary.nix (which is just an update of cef-binary in nixpkgs):

{ cef-binary }:
let
  version = "149.0.4";
in
(
  if (cef-binary.version == version) then
    cef-binary
  else
    (cef-binary.override {
      inherit version;
      gitRevision = "2f1bfd8";
      chromiumVersion = "149.0.7827.156";
      srcHashes = {
        aarch64-linux = "sha256-iQmnlonux7I+2ACEtpdmlS1E4A+aNFgylRsykD+KgKA=";
        x86_64-linux = "sha256-bUNgdnXkfta/pA0c/OE20E53IFKfjxxENdS6Hc0YObI=";
      };
    })
).overrideAttrs
  (old: {
    passthru = old.passthru // {
      updateScript = ./update-cef.sh;
    };
  })

I'll call the resulting derivation pkg in the following.

builtins.unsafeGetAttrPos something pkg, where something is "version" or "src" for instance, returns the position in the original cef-binary/package.nix file in nixpkgs.

Expected behavior

As for the column and line attributes of the returned value, I have no opinion, but file should be /nix/store/XXXXXX-source/path/to/new-cef-binary.nix.

Metadata

nix-env (Nix) 2.34.7

Additional context

A hack for this issue is to simply inherit the old attributes in overrideAttrs, as in the following example:

{ cef-binary }:
let
  version = "149.0.4";
in
(
  if (cef-binary.version == version) then
    cef-binary
  else
    (cef-binary.override {
      inherit version;
      gitRevision = "2f1bfd8";
      chromiumVersion = "149.0.7827.156";
      srcHashes = {
        aarch64-linux = "sha256-iQmnlonux7I+2ACEtpdmlS1E4A+aNFgylRsykD+KgKA=";
        x86_64-linux = "sha256-bUNgdnXkfta/pA0c/OE20E53IFKfjxxENdS6Hc0YObI=";
      };
    })
).overrideAttrs
  (old: {
    # make nix understand that src and version are defined in this file
    inherit (old) src version;

    passthru = old.passthru // {
      updateScript = ./update-cef.sh;
    };
  })

Checklist

• checked latest Nix manual (source)
• checked open bug issues and pull requests for possible duplicates

---

Add 👍 to issues you find important.

[xokdvium]

Probably not a bug, but just how current semantics works: #13759 (comment).

[xaltsc]

Probably not a bug, but just how current semantics works: #13759 (comment).

I don't understand at all the internals of nix, but, ooc, does the issue you've mentioned propose a change in semantics ?

[xokdvium]

does the issue you've mentioned propose a change in semantics

It was proposed, but I'm not sure it would progress. It seems like there are different positions one might want to query and propagate. Either the location of the attribute name (the current semantics) or the location of the value. Both are reasonable and existing tooling relies on the former. I'm not sure how feasible it would be to track both positions - we might not have enough spare memory for that. Breaking the current semantics would certainly be a bit of a tradeoff, and might do more harm than good.