Question about .eval

[zenoli]

I cannot wrap (no pun intended) my head around the implementation of the .eval function. This is taken from Lassulus' .apply function.
My understanding of myModule.extendModules { ... } is that it extends myModule with new options and configs provided in the module list. Isn't this already what we want?

What is the reasons of using _moduleSettings here? After having played around with the nix repl, chaining calls of .eval creates some sort of "history" of the module arguments that were provided in each call. But I don't see why it is needed.

        eval = lib.mkOption {
          type = lib.types.functionTo lib.types.raw;
          readOnly = true;
          description = ''
            Function to extend the current configuration with additional modules.
            Re-evaluates the configuration with the original settings plus the new module.
            Returns the raw evaluated module.
          '';
          default =
            module:
            evaled.extendModules {
              modules = [
                config._moduleSettings
                module
                {
                  _moduleSettings = lib.mkForce {
                    imports = [
                      config._moduleSettings
                      module
                    ];
                  };
                }
              ];
            };
        };

[BirdeeHub]

My understanding of myModule.extendModules { ... } is that it extends myModule with new options and configs provided in the module list.

Yeah you would think that would be what it does, right?

I mean, its named extendModules and it certainly looks like it stores the ones from the call to evalModules in a variable called regularModules, and then when you call extendModules it adds the new ones to that list and re-calls evalModules with the new list.

I would think that it would extend them.

Problem is, if you don't store them like this, it doesn't seem to store any of the config values only the options? And so it warns that pkgs was accessed but not defined?

I honestly am also somewhat confused. Ive been reading the source code of evalModules and it certainly LOOKS like it should not be necessary to do this? But it really seems to be?

Edit: It might also be because each time, we call it from the same evaled variable.

Rest assured, if I figure out how to remove that, I very much will

Edit 2:

It is because each time, we call it from the same evaled variable. I will come up with a better way to do this.

Regardless, dont set or use the value yourself, it is labelled internal for a reason XD

[BirdeeHub]

It now should make more sense. We still need an internal option though, _moduleSettings was just not the correct one.

It is now __extend and it holds the value of res.extendModules after each re-evaluation

In order to achieve this, Because the module actually carries everything over now properly, I could not just mkForce the thing, because then I would mkForce multiple times and run into the same problem.

So I had to make it a type in which the last assignment always is the winner.

[zenoli]

Im not sure if it is possible to wrap it up much nicer, although I could maybe allow for a 4th exposed function option which exposes the whole set of extendModules arguments. Or maybe allow the existing ones to take [ "raw" { extendModulesArgs } ] if desired, which is distinct from a list of modules because a string is not a module.

Doing 1 of those 2 things would make it so that you never have to manually call extendModules under any circumstances, as you would already have the ability to do that, but easier.

I kinda like the [ "raw" { extendModulesArgs } ] because it gives the option of all 3 outputs and doesnt add another option.

However, at the same time, it makes the existing functions slightly more complex. I am unsure which is more confusing. Figuring out when to use the new one, or figuring out the [ "raw" { extendModulesArgs } ] thing.

If it is about the same either way, I prefer the [ "raw" { extendModulesArgs } ] way to be honest, as it adds more options than adding a new function, and does so with less code, and doesn't feel that crazy to me.

The only reason to use that at all though, would be to set prefix or specialArgs posthumously. As those are the only other 2 values extendModules grabs from its arguments. And specialArgs you can already basically do posthumously with _module.args, and you can already call wlib.evalModules and supply either of those on initial eval. The relatively small utility of adding this feature makes me lean even more away from it getting its own 4th dedicated function.

I don't see any usecase where where exposing all extendModules would be of a significant benefit.

The "raw" argument workaround seems a bit hacky to me. I would prefer sticking to the simple and more readable solution for now and keep this thread as a reference in case an urgent need for this comes up. The "raw" implementation to posted is 100% backwards compatible, so it could easily be added in the future. But if it turns out no-one will ever use it, it is just technical debt.

[BirdeeHub]

If it proves necessary for something I'll probably add it as just an extra function, because people collecting the argument for some reason would then need to check that too if they wanted to append to it. My opinion on that is different than it was earlier after more consideration lol

But yeah, also not particularly important so Im just going to say "maybe later" on that one for now

[BirdeeHub]

I learned more things.

mkOverride

only the highest priority created using mkOverride, including mkDefault and mkForce, is shown in merge defs argument

mkOrder

priority field makes it into the merge function. This is for mkOrder, i.e. mkAfter and mkBefore

[BirdeeHub]

I DID IT

I MADE overrideAttrs AND override WRAP THEIR RESULT BACK INTO THE MODULE SYSTEM SO IT DOESNT DISAPPEAR NEXT TIME YOU CALL .wrap AHAHAHHA

[BirdeeHub]

and symlinkScript can return a function now for maximum control over the final DRV

It can return either a string, or a function from attrs to attrs

[BirdeeHub]

Going to close this because it isnt going to be useful for anyone anymore given it now works in a more understandable way, so people don't need to be able to easily find this.

[BirdeeHub]

You might find this PR interesting #91

It added this https://birdeehub.github.io/nix-wrapper-modules/core.html#overrides

It didnt touch how __extend works, but it changed how I was wrapping .override and .overrideAttrs back into the module system.

__extend is now once again the only internal option.

Also this one #97

[BirdeeHub]

2-3 weeks until neovim wrapper.

Im a few days away from a working prototype, and Im going to mess around with it, refine it, fix up the descriptions for it and write a detailed description, write some tests and a template for it, and then its done.

[BirdeeHub]

btw there were some setbacks but it is still on the way. But its still a few weeks out.

My original interface design wasn't quite what I wanted.

But.... wlib.types.subWrapperModuleWith is a thing now! So thats cool!

[BirdeeHub]

d18e8c9

You can call .extendModules now. Also there is a config.extendModules people can use. And a proper subWrapperModule type.