[regression?] build failure (via HM-module), suspected cause: new wrapper

ppenguin commented 1 month ago

⚠️ Please verify that this bug has NOT been reported before.

[X] I checked all existing issues and didn't find a similar issue

Description

Rebuilding my HM config after flake inputs to nvf/master (with folllows nixos-unstable) causes build failure:

(see Log Output)

Reverting the flake input to a commit before the wrapper change makes the config build successfully.

👟 Reproduction steps

Rebuild a HM config after updating to nvf/main that used to work previously, defined like this:

  imports = [
    inputs.nvf.homeManagerModules.default
    ...
  ];

  programs.nvf = {
    enable = true;
    settings = {
        ...
    };
...

fails.

👀 Expected behavior

Succesful build.

😓 Actual Behavior

Build failure, see above.

💻 Metadata

nix-shell -p nix-info --run "nix-info -m" - system: "x86_64-linux" - host os: Linux 6.9.7-zen1, NixOS, 24.11 (Vicuna), 24.11.20240712.7e7c39e - multi-user?: yes - sandbox: yes - version: nix-env (Lix, like Nix) 2.90.0-pre20240710-2a4376b - nixpkgs: /nix/store/avr7mz0wf0vqqm6w4y3z9an2g4c29b2v-xr9wjzx0cdnwkmhzz74h8lphgn5jmyv3-source

📝 Relevant log output

...
       … while calling the 'getAttr' builtin
         at /builtin/derivation.nix:1:500:
       … while calling the 'derivationStrict' builtin
         at /builtin/derivation.nix:1:208:
       … while evaluating derivation 'neovim-0.10.0'
         whose name attribute is located at /nix/store/qmh8bas1qni03drm0lnjas2azh7h87cn-source/pkgs/stdenv/generic/make-derivation.nix:334:7

       … while evaluating attribute 'installPhase' of derivation 'neovim-0.10.0'
         at /nix/store/fxd3xvrrl37lj9irxcw4qii7jcijb155-source/wrapper.nix:233:5:
          232|
          233|     installPhase = ''
             |     ^
          234|       runHook preInstall

       … while calling the 'getAttr' builtin
         at /builtin/derivation.nix:1:500:
       … while calling the 'derivationStrict' builtin
         at /builtin/derivation.nix:1:208:
       … while evaluating derivation 'init.lua'
         whose name attribute is located at /nix/store/qmh8bas1qni03drm0lnjas2azh7h87cn-source/pkgs/stdenv/generic/make-derivation.nix:334:7
...
       … while evaluating attribute 'buildCommand' of derivation 'packdir'
         at /nix/store/qmh8bas1qni03drm0lnjas2azh7h87cn-source/pkgs/build-support/trivial-builders/default.nix:68:17:
           67|         enableParallelBuilding = true;
           68|         inherit buildCommand name;
             |                 ^
           69|         passAsFile = [ "buildCommand" ]
...
       … while calling the 'parseDrvName' builtin
         at /nix/store/qmh8bas1qni03drm0lnjas2azh7h87cn-source/lib/strings.nix:730:19:
          729|   getName = let
          730|     parse = drv: (parseDrvName drv).name;
             |                   ^
          731|   in x:

       … while evaluating the first argument passed to builtins.parseDrvName

       error: attribute 'name' missing
       at /nix/store/qmh8bas1qni03drm0lnjas2azh7h87cn-source/lib/strings.nix:734:28:
          733|     then parse x
          734|     else x.pname or (parse x.name);
             |                            ^
          735|

NotAShelf commented 1 month ago

I am unable to reproduce this error: my configuration at latest HEAD & default packages provided by nvf both work as intended with the wrapper.

It could be a regression specific to your configuration, would you be able to attach your nvf configuration in full?

NotAShelf commented 1 month ago

It would also be great if you could attach the full logo output, this seems to be truncated?

ppenguin commented 1 month ago

@NotAShelf Thanks for looking into it! I've committed the full log and full config here: https://github.com/ppenguin/_nvf-config

And to understand the (flake) inputs better, I've also included a reference of my "flake system" (the whole flake is not yet public because I haven't gotten around to sanitize and refactor it yet).

NotAShelf commented 1 month ago

I've been dissecting your configuration for a while. To be fair, I am not quite sure what exactly is the reason behind the issue. Judging by one of the error messages, it could be optPlugins.

Could you try updating nvf and adding your plugins to vim.extraPlugins?

ppenguin commented 1 month ago

I've been dissecting your configuration for a while. To be fair, I am not quite sure what exactly is the reason behind the issue. Judging by one of the error messages, it could be optPlugins.

Could you try updating nvf and adding your plugins to vim.extraPlugins?

Yes, that fixed it! I must admit that I have no clue why, but at least it seems to work. Somehow my config diff showed a lot of plugins I previously had as removed, but I haven't gotten around testing that further (I haven't used many of my "standard" plugins under nvf yet).

I'll close this now, I assume optPlugins will be removed? Maybe a convenience function would be nice, to use less boiler plate for plugins that don't require setup or ordering, TBH it's nice to be able to use lists for that instead of attrsets).

NotAShelf / nvf