Attribute 'packageName' missing - beamModules update to fixed point

[bfolkens]

Recent updates in nixpkgs beamModules transitioned to fixed point (8bdef3ae032ed12b5bbec548e3a65cf020adf457), which seems to be causing new errors (below):

error:
       … while calling the 'derivationStrict' builtin
         at <nix/derivation-internal.nix>:37:12:
           36|
           37|   strict = derivationStrict drvAttrs;
             |            ^
           38|

       … while evaluating derivation 'example-0.1.0'
         whose name attribute is located at /nix/store/3x925rhb3gjikmqkyqigjcdfqm1hsn6a-source/pkgs/stdenv/generic/make-derivation.nix:536:13

       … while evaluating attribute 'configurePhase' of derivation 'example-0.1.0'
         at /nix/store/3x925rhb3gjikmqkyqigjcdfqm1hsn6a-source/pkgs/development/beam-modules/mix-release.nix:172:5:
          171|
          172|     configurePhase =
             |     ^
          173|       attrs.configurePhase or ''

       (stack trace truncated; use '--show-trace' to show the full, detailed trace)

       error: attribute 'packageName' missing
       at /nix/store/qbx2i8d4y4nzgy2ilaz9xs23hm7mzqkj-source/nix/deps.nix:102:54:
          101|               | xargs grep 'defmodule' \
          102|               | sed 's/defmodule \(.*\) do/config :${old.packageName}, \1, skip_compilation?: true/'
             |                                                      ^
          103|             echo "***********************************************"

[camelpunch]

@adamcstephens I've had a look at this and am getting confused by the new patterns in nixpkgs.

Naively, if I update nixpkgs in deps_nix and change old.packageName to old.name, I get a further error, when the overrides for rust attempt to read the old.buildPhase in order to add a trap:

error: attribute 'buildPhase' missing

There must be a more elegant, working way to do this but I'm at a bit of a loss. Could you give any advice?

This is reproducible with nix flake check inside deps_nix.

[adamcstephens]

I took a look at this, but it's going to require some more investigation so I'll have to come back to it. Here are some notes.

• name is not a simple module name, it's erlang28.4.1-tokenizers-0.3.1 now. we can use beamModuleName or expose pname through nixpkgs. This affects the copying of the native binary into place.
• drv.override is no longer the proper interface to use. we'll need to use overrideAttrs or set up the builder directly rather than overriding. This also means that changes such as nativeBuildInputs = [ extendedPkgs.cargo ] ++ old.nativeBuildInputs; need to happen in the case of overrideAttrs
• old.buildPhase does in fact no longer exist. You'll need to drop that, and it's best to not override buildPhase, so I'd rename to preBuild.

While looking at this, I'm wondering if it may be better long term to migrate this rustlerPrecompiled into a setup hook in nixpkgs, but that's probably for later.

There's also a question of backward compatibility. The fixed point refactors are only in unstable and will never be backported. It's probably cleaner to not add compatibility to 25.11, but it should be noted in a release that includes them.

[camelpunch]

Yeah probably easiest with a major version bump and a big warning.

[camelpunch]

Thanks for investigating!

[camelpunch]

Beneath more layers lies buildRebar3 trouble. Is it valid now to say overrideAttrs { prevAttrs: { buildplugins = [ beamPackages.pc ]; }}? If not, how do we set plugins for rebar3 builds?

[adamcstephens]

Yeah, it's buildPlugins in an override. https://github.com/NixOS/nixpkgs/blob/7611a64b170a6765f93e96bb87a4e5c042a52353/pkgs/development/beam-modules/build-rebar3.nix#L27

e.g. an example from nixpkgs

      syslog = prev.syslog.override { buildPlugins = with beamPackages; [ pc ]; };

[camelpunch]

Ah OK, so override isn't going away for rebar3 derivations? My confusion continues!

[adamcstephens]

Well, it depends on what you're trying to do. override modifies the argument attrset of the builder function you're calling. In this case if you look at buildRebar3 you'll see buildPlugins is in the args, and then it's used to construct a custom rebar3 package that gets included into the final derivation.

In the case of buildMix above, you're wanting to extend the final attrset to add more packages to in which case you're adding to the resulting attrset and thus use overrideAttrs.

[adamcstephens]

I'm sorry if I sent you down the wrong path with overrideAttrs. I was wrong, and override is fine for these builders still. I've opened #47