Flake-parts: option `flake.modules' is defined multiple times while it's expected to be unique

Help
1

Out of fascination for flake-parts and the dendritic pattern, I am (slowly) re-factoring my NixOS config repository turning every file into a flake module.

Let’s assume I have a host (host A) for which I’d like to split its configuration in two (for simplicity):

hardware.nix (with the contents of the original hardware-configuration.nix)
default.nix (all the rest).

Currently what I have is:

### default.nix
{
    flake.modules.nixos.hostA = {
        imports = with config.flake.modules.nixos.hostA; [
            hardware
        ];
    };
}

### hardware.nix
{
    flake.modules.nixos.hostA.hardware = ...
}

This should work (at least from my understanding), and simply import the contents of hardware.nix as a flake submodule, but I get:

error: The option `flake.modules' is defined multiple times while it's expected to be unique.
       No option has been declared for this flake output attribute, so its definitions can't be merged automatically.
       Possible solutions:
         - Load a module that defines this flake output attribute
           Many modules are listed at https://flake.parts
         - Declare an option for this flake output attribute
         - Make sure the output attribute is spelled correctly
         - Define the value only once, with a single definition in a single module

       Definition values:
       - In `/nix/store/79r2psqbf7qk7i59ngbvy78zxv8lvx7y-source/modules/hosts/hostA/default.nix':
           {
             nixos = {
               host_A = <function, args: {config, inputs, lib, options, outputs, pkgs}>;
             };
           }
       - In `/nix/store/79r2psqbf7qk7i59ngbvy78zxv8lvx7y-source/modules/hosts/hostA/hardware.nix':
           {
             nixos = {
               host_A = {
                 hardware = <function, args: {config, lib, modulesPath, pkgs}>;
               };
           ...
       Use `lib.mkForce value` or `lib.mkDefault value` to change the priority on any of these definitions.

Why does it happen? There are plenty of examples out there of people effectively employing a similar logic.

2

You need to import the flake-parts module (via inputs.flake-parts.flakeModules.modules) under the imports section of the flake (probably via mkFlake). Make sure you do so that the options that permit what you want, start working then.

This section of their docs is for this feature: modules - flake-parts

1 Like
3

Thanks for your reply. I forgot to mention that I use import-tree, so all flake modules under the specified directory tree are automatically imported (at least, from my understanding). For reference, here is the structure of my flake.nix:

{
    description = "...";
    inputs = { ... };
    outputs =
        { flake-parts, ... }@inputs:
        flake-parts.lib.mkFlake { inherit inputs; } (inputs.import-tree ./modules);
}

The two modules I described in my previous message are included in the modules/ directory. Is there still the need to import them specifically as you suggested?

4

Hello,

Just create this file in your ./modules directory and it should be OK: infra/modules/flake-parts/flake-parts.nix at 82a59a2aa13e044ef633899213a36b50b593163e · drupol/infra · GitHub

1 Like
5

@drupol, that was the bit I was missing, thank you. Now everything works accordingly. :slight_smile:
@Michael-C-Buckley thanks for providing the relevant documentation, I certainly have some more reading to do :smiley:

1 Like
6

You’re welcome !

Feel free to use my infra repo as example.

1 Like
7

@drupol, while you’re here, I think there is still a bit I’m missing.
I am refactoring my repo to something which looks like this:

### default.nix (infinite recursion)
{
    flake.modules.nixos.hostA = { inputs, config, pkgs, ...}: {
        imports = [
            ./_path_to_some_nix_module
            config.flake.modules.nixos.hostA.hardware
        ];
    };
}

### hardware.nix (infinite recursion)
{
    flake.modules.nixos.hostA.hardware = { inputs, config, pkgs, ...}: {
        ...
    };
}

Which however results in infinite recursion upon evaluation. This doesn’t happen if I split flake.modules.nixos.hostA over the two files, rather than assigning the content of hardware.nix to the .hardware attribute:

### default.nix (no infinite recursion)
{
    flake.modules.nixos.hostA = { inputs, config, pkgs, ...}: {
        imports = [
            ./_path_to_some_nix_module
        ];
    };
}

### hardware.nix (no infinite recursion)
{
    flake.modules.nixos.hostA = { inputs, config, pkgs, ...}: {
        ...
    };
}

I guess this happens because I have config both in the head and body of the function (imports) in default.nix, am I right?
I guess this refactoring is gonna take quite some time. If you have any tips on easing the process, I am all ears (I spotted a _to_migrate directory in the root of your infra repo, so I guess similar issues are faced by many seasoned nixers facing the migration to the dendritic pattern…) :smiley:

1 Like
8

you are almost there!, try using imports = [ self.modules.nixos.hostA ], that is, instead of using config (which you cannot depend on import) try using the flake exposed output modules. here’s an example in my old infra (old as in previous week, haha). Hope you having a lot of fun with the Dendritic pattern, it is worth learning.

EDIT: regarding the migration path, I know some people also have the need for having non-dendritic files around (like for auto-generated hardware configuration from tools that have no notion of the dendritic pattern), or just having directories like the _to_migrate you mention. my new library den (to which I’m moving my infra since last week) acknowledges this need, and allows people to auto-import from non-dendritic directories, since I want more people to try the dendritic pattern and having a better migration path is a must have for that.

2 Likes
9

another btw, (hahaa) I also can recommend the unify framework which is being used by drupol, I believe. there are certainly much more people using it than my newly-fresh den lib. configs in it are also very nice and clean. see quasigod’s for a taste! (link in the unify repo).

1 Like
10

Find it in this PR: refactor: use `unify` framework by drupol · Pull Request #84 · drupol/infra · GitHub

The PR is outdated since 2~3 days, I will update it later. Basically I haven’t fully switched to unify because I wanted to carefully test it… and I really like it indeed, I might merge that PR soon.

1 Like