Loading wrapper modules

[zenoli]

Is this correct:

The expression in modules/default.nix essentially loads all wrapperModules from all directories:

{
    a = {
        wrapperModules = { 
            alacritty = module;
            audacity = module;
        };
        checks = { 
            alacritty = { ... };
            audacity = { ... };
        };
    };
    b = {
        wrapperModules = { 
            bmenu = module;
        };
        checks = { 
            bmenu = module;
        };
    };
    ...
}

and then finally merges them into:

{
        wrapperModules = { 
            alacritty = module;
            audacity = module;
            bmenu = module;
        };
        checks = { 
            alacritty = { ... };
            audacity = { ... };
            bmenu = { ... };
        };
    ...
}

The "library modules" (makeWrapper, symlinkScript) are not included in wrapperModules?

[BirdeeHub]

They are not thay are just modules. They don't set package option, so they are not wrapping anything, thus not wrapperModules. They are in wlib.modules and the raw wrapperModules paths are in wlib.wrapperModules

And then from the top level of the flake, the result of .apply is exposed for easy access to .wrap under outputs.wrapperModules and wlib is exported as outputs.lib

Within the modules, you should be grabbing wlib via your module arguments. Outside of calling evalModule on the thing originally, you likely will not need it outside of the module after that.

[BirdeeHub]

Ok. Just FYI: The nixpkgs style guide recommends hyphenated file and dir names: https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#file-naming-and-organisation

Thats ok. The 1 thing that is guaranteed to break if it gets put into nixpkgs is the location of the files XD disabledModules users will expect that one XD The helper modules inside are named the same as their attribute, as are the wrapper modules, seemed like a good convention

If I was going to name it something other than the name of the attribute, I would have named it wrappers

[zenoli]

Another understanding question:
When creating the modules key:

  modules = (helper_mod_res.modules or { }) // {
    default = {
      imports = [
        wlib.modules.symlinkScript
        wlib.modules.makeWrapper
      ];
    };
  };

Doesn't that lead to an attr set like this?

modules = {
    symlinkScript = ...
    makeWrapper = ...
    default = { *merged symlinkScript and makeWrapper* }
}

But we only use modules.default? Why expose them on the top level?

[BirdeeHub]

you can import them separately. You may wish to import something else instead of makeWrapper but keep symlinkScript or something

For example you could use makeWrapperNix instead of makeWrapper as the wrapper implementation to use alongside symlinkScript

.default is just suggesting you a starter pokemon. Its just an alias for convenience and to point it out. It is also pre imported by wrapModule and wrapProgram convenience functions. Its likely all you need for 90+% of wrapper modules

[zenoli]

Thank you for all the explanations.
This discussion cleared things up for me.
There are two classes of modules. "Helper modules" which now live in ./modules aimed to provide assistance when creating wrapper by leveraging the module system and "wrapper modules" which now live in ./wrapperModules containing a collection of pre-defined modules to configure wrappers for specific applications.

[BirdeeHub]

yes. Wrapper modules set package option other modules do not. Other than that, they are both just modules.

The core options are super minimal and flexible, your helper module(s) of choice creates convenience options for you and the users of your wrapper, you use those to add a few program specific things and set the package option, and then you have yourself a nice wrapper module for a program :)