Make one wrapper depend on another wrapper in flake-parts module?

[zenoli]

Having been away for a couple of weeks, it is amazing to see how far this project has come!
Especially the flake-parts module and the ability to integrate these modules as native nixos/hm modules seems like great ideas, so I wanted to give them a try.
When playing around with flake-parts module, I encountered a problem:

I have a custom zsh-wrapper module (zsh.nix) that I would like to depend on another wrapper module (direnv.nix).
However, using the flake parts approach, I fail to express this dependency (marked with ???) in flake.nix. Is there a way around it?

{
  description = ''
    Uses flake-parts to set up the flake outputs:

    `wrappers`, `wrapperModules` and `packages.*.*`
  '';
  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixpkgs-unstable";
    wrappers = {
      url = "github:BirdeeHub/nix-wrapper-modules";
      inputs.nixpkgs.follows = "nixpkgs";
    };
    flake-parts = {
      url = "github:hercules-ci/flake-parts";
      inputs.nixpkgs-lib.follows = "nixpkgs";
    };
  };
  outputs =
    {
      self,
      nixpkgs,
      wrappers,
      flake-parts,
      ...
    }@inputs:
    flake-parts.lib.mkFlake { inherit inputs; } {
      systems = nixpkgs.lib.platforms.all;
      # Import the flake-parts module:
      imports = [ wrappers.flakeModules.wrappers ];
      flake = {
        wrappers = {
          direnv = { pkgs, wlib, ... }: {
            imports = [ (import ./direnv.nix) ];
          };
          zsh = { pkgs, wlib, ... }: {
            imports = [ (import ./zsh.nix) ];
            starship = {
              enable = true;
            };
            direnv = {
              enable = true;
              package = ??? # <-- I want to use something like `self'.packages.direnv` here  
            };
            fzf = {
              enable = true;
            };
            plugins = [ 
              { 
                package = pkgs.zsh-fzf-tab; 
                name = "fzf-tab";
              }
              { 
                package = pkgs.zsh-vi-mode;
                init = "zvm_after_init_commands+=('source <(fzf --zsh)')";
              } 
              { 
                package = pkgs.oh-my-zsh;
                file = "plugins/git/git.plugin.zsh";
                disable = true;
              } 
            ];
          };
        };
      };
    };
}

[zenoli]

Nevermind, I should have simply read the documentation first :-)

I could achieve what I wanted using withSystem:

{
  description = ''
    Uses flake-parts to set up the flake outputs:

    `wrappers`, `wrapperModules` and `packages.*.*`
  '';
  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixpkgs-unstable";
    wrappers = {
      url = "github:BirdeeHub/nix-wrapper-modules";
      inputs.nixpkgs.follows = "nixpkgs";
    };
    flake-parts = {
      url = "github:hercules-ci/flake-parts";
      inputs.nixpkgs-lib.follows = "nixpkgs";
    };
  };
  outputs =
    {
      self,
      nixpkgs,
      wrappers,
      flake-parts,
      ...
    }@inputs:
    # flake-parts.lib.mkFlake { inherit inputs; } {
    flake-parts.lib.mkFlake { inherit inputs; } (top@{ config, withSystem, moduleWithSystem, ... }: {

      systems = nixpkgs.lib.platforms.all;
      # Import the flake-parts module:
      imports = [ wrappers.flakeModules.wrappers ];
      flake = {
        wrappers = {
          direnv = { pkgs, wlib, ... }: {
            imports = [ (import ./direnv.nix) ];
            nix-direnv.enable = true;
          };
          zsh = { pkgs, wlib, ... }: {
            imports = [ (import ./zsh.nix) ];
            starship = {
              enable = true;
            };
            direnv = {
              enable = true;
              package = withSystem pkgs.stdenv.hostPlatform.system (    # <-- solution
                  { config, ... }: # perSystem module arguments
                  config.packages.direnv
                );
            };
            fzf = {
              enable = true;
            };
            plugins = [ 
              { 
                package = pkgs.zsh-fzf-tab; 
                name = "fzf-tab";
              }
              { 
                package = pkgs.zsh-vi-mode;
                init = "zvm_after_init_commands+=('source <(fzf --zsh)')";
              } 
              { 
                package = pkgs.oh-my-zsh;
                file = "plugins/git/git.plugin.zsh";
                disable = true;
              } 
            ];
          };
        };
      };
    });
}

The flake-parts module is so cool, kudos @BirdeeHub !

[zenoli]

I also tried using wlib.mkInstallModule but I am not sure whether I am using it correctly:

The idea is to use it in imports of my zsh wrapper module and install the package to my custom defined runtimePackages option (which takes a list of lib.types.package and adds them to $PATH.)

  imports = [
    (wlib.mkInstallModule {
      name = "direnv";
      as_list = true;
      loc = [ "runtimePackages" ];
      optLoc = [ "integrations" ];
      value = ../../direnv.nix;
    })
  ];

However, if I try using it with config.integrations.direnv.enable = true; the option is not found:

error: The option `flake.wrappers.zsh.integrations' does not exist. Definition values:
       - In `/nix/store/n2adk6b1csx8nwrvd88nvs1pqlrfgsdz-source/wrapper-modules/zsh/modules/integrations.nix':
           {
             direnv = {
               enable = true;
             };
           }

       Did you mean `flake.wrappers.zsh.env', `flake.wrappers.zsh.meta' or `flake.wrappers.zsh.pkgs'?

Is wlib.mkInstallModule only supposed to be used with "plain nixos modules" or can you spot something else I am doing wrong?

[BirdeeHub]

It works with nixos and home-manager by setting environment.systemPackages or home.packages

But it is simply a wrapper around the wlib.types.subWrapperModule type.

Here is a simplified version of basically what it does.

{ config, pkgs, lib, ... }: {
  # it just declares it 1 level deeper, it isnt even an attrsOf type
  options.myoption.nameofthing = lib.mkOption {
    type = wlib.types.subWrapperModule [
      { inherit pkgs; }
      { options.enable = lib.mkEnableOption "my sub wrapper module"; }
      your modules here
    ];
    default = {};
  };
  config.home.packages = lib.mkIf config.myoption.nameofthing.enable [
    config.myoption.nameofthing.wrapper
  ];
}

The arguments are

{
  name, # string
  value, # module or list of modules
  optloc ? [ "wrappers" ], # <-- I don't know why this is not camel case but it is not
  loc ? [
    "environment"
    "systemPackages"
  ],
  as_list ? true, # <- also why is this snake case. The only reason I did snake case for some stuff in the neovim module was to show that item gets auto-translated....
  # Also accepts any valid top-level module attribute
  # other than `config` or `options`
  ...
}:

One reason you are having an issue is because there apparently is inconsistent capitalization, and the arguments have ... so it does not tell you that optLoc does not exist apparently (it would eventually, as optLoc is probably not an option you have defined in the target module either, but like, that error triggered first)

---

I don't know how you have integrations option defined in your zsh module

It would either have to be a submodule type, or not defined directly (just directly define nested options) for it to work.

Only submodule types allow directly nested declaration of options like that, which is why subWrapperModule is an alias for submodule, rather than having its own name.

[zenoli]

One reason you are having an issue is because there apparently is inconsistent capitalization, and the arguments have ... so it does not tell you that optLoc does not exist apparently (it would eventually, as optLoc is probably not an option you have defined in the target module either, but like, that error triggered first)

Omg... I totally missed this. Thank you!

Even after I fixed this, I ran into another error, I think it had something to do with what you wrote:

It would either have to be a submodule type, or not defined directly (just directly define nested options) for it to work.

My (now abandoned) idea was as follows:

Declare a type integrations which is an attrsOf integration. integration is a custom submodule consisting of the options:

• package: a package to integrate (fzf, direnv etc)
• enable: an enable option for the integration
• init: a string which initializes the integration in zshrc (for example source <(fzf --zsh))

This way, I don't have to define all possible integrations statically in the wrapper module but can simply add entries to the integrations set and the module will dynamically generate the appropriate config in .zshrc.

Now I also wrote a wrapper module for direnv which, for example defines a config nix-direnv.

My goal was to keep the aforementioned "dynamic configurability" but also merge subwrapperModules such as direnv in a natural way, such that I can configure stuff like this:

  integrations = {
    fzf = {    # <-- there is no "fzf" wrapper module, fzf is completely set up by the configuration you see here
      enable = lib.mkDefault true;
      init = "source <(fzf --zsh)";
    };
    direnv =
      enable = lib.mkDefault true;
      settings = {  # <-- these settings are provided by the "injected" direnv subWrapperModule
        nix-direnv.enable = true;
      };
    };
  };

The way I wanted to "inject" the direnv wrapper module into integrations.direnv.settings was to use mkInstallModule and adjust the options:

• loc & as_list=false: to overwrite the integrations.direnv.package value with direnv.wrapper
• optloc: to "inject" the module into integrations.direnv.settings.

However a combination of infinite recursion errors and my inexperience with nix and the module system prevented me from succeeding :-)

I now managed to achieve the same goal with another approach, based on subWrapperModule and without mkInstallModule.

integrations is now a normal submodule with freeformType = integration (the integration type is the same as above).

Every "explicit" integration that is based on a wrappermodule is then listed in this submodule:

  options = {
    integrations = lib.mkOption {
      default = {};
      type = lib.types.submodule ({ config, ...}: {
        freeformType = lib.types.attrsOf integration;
        options = {
          direnv = mkWrapperIntegrationOption ../../direnv.nix;  
        };
      });
    };
  };

mkWrapperIntegrationOption is implemented as follows:

  wrapperIntegrationWith = wrapperModule: lib.types.submoduleWith {
    modules = [
      ({config, ... }: {
        options.settings = lib.mkOption {
          type = wlib.types.subWrapperModule wrapperModule;
        };
        config.settings.pkgs = lib.mkDefault pkgs;
        config.package = lib.mkDefault config.settings.wrapper;
      })
      integratable  # <-- a module providing `enable, package and init` options. The integration type is based on this as well
    ];
  };
  mkWrapperIntegrationOption = wrapperModule: lib.mkOption {
    type = wrapperIntegrationWith wrapperModule;
  };

[BirdeeHub]

Yes I think that looks like a reasonable way to do it.

Also, you can still declare options there from anywhere, so that is good because you can add such an integration from later .wrap calls and other modules and stuff

i.e. you should be able to do this from wherever:

options.integrations.anotherone = mkWrapperIntegrationOption ./someothermodule.nix;

You should also be able to put the function in a readOnly option so you have access to the function there without having to pass it around as well.

options.mkWrapperIntegrationOption {
  type = lib.types.raw;
  readOnly = true;
  default = mkWrapperIntegrationOption;
};

And then you could just grab it

options.integrations.anotherone = config.mkWrapperIntegrationOption ./someothermodule.nix;

If that throws from infinite recursion, you would probably just need to do that with wrapperIntegrationWith instead but it should be fine.

Cool stuff! Thanks for sharing!

[zenoli]

You should also be able to put the function in a readOnly option so you have access to the function there without having to pass it around as well.

Oh yes, will def add this, thx!