This is like 4 libraries in one?!

[removed-user]

Literally, a core DAG engine, wrapper tooling, a module system adapter, and application-specific configurations.

Honestly, I just want the module system adapters?

Would it be difficult to separate that out into its own flake/module? and import it here?

edit: Not to be a downer or anything, I do appreciate the work, it looks like a lot of very useful functions, sure it took time;

Just asking if it's more tightly coupled than I realize? Would it require a lot of changes to be able to factor those out?

[BirdeeHub]

Well, the "DAG engine" is a combination of a single nix type called wlib.types.specWith, which auto normalizes a value, and lib.lists.toposort from nixpkgs.

It is just a type, and a sorting function from nixpkgs, more or less. It is an "extra" thing, but one which we use quite a bit.

---

The point is, generate wrapper derivations using the module system.

Then, in addition, we have an attribute set of modules with application specific configurations for more fine-grained options for specific programs.

Theoretically, if we were to split it, there are 2 things in this repo. The split would be:

wlib and the wlib.modules set in 1 repo (lib/* and modules/*)

and then wrapperModues/*/*/module.nix (wlib.wrapperModules) in another repo.

But, in wlib.wrapperModules is JUST the paths to those modules. They do not have a runtime cost you pay for if you do not use them, beyond the direct size of the files from this repo as an input.

Nixpkgs has a mirrored nixpkgs-lib repo, and something similar would likely be the best thing to do here too, but it hasn't felt like necessary complexity yet.

---

The module system is much simpler to call than you might think. You might not need an adapter for your purpose.

We are calling it with some existing options tailored to making wrapper derivations. It calls lib.evalModules with the wlib.core module imported. It outputs the wrapper at config.wrapper. That much is coupled. Almost every wrapper module provided here will also import wlib.modules.default. You as a user, then add your own modules to that to set the options that creates.

If you want to make a thing and accept some options, set up a value to have as an output, and if you have just a few it can be reasonably used as a submodule too elsewhere, like we do with our wrapper modules.

---

Basically, the nixpkgs module system is a tool for doing a specific task with well documented options which can be overridden.

A task may have a lot of options associated with doing it, such as "creating a wrapper derivation" or "managing a user" but the lib.evalModules function just evaluates with whatever modules you give it and validates the result, and then you grab what you want from the result. Each of these systems (nixos, home manager, nix-darwin, devenv, and nix-wrapper-modules) wraps it to give it a different base set of options, and have a different set of result outputs it grabs. We output config.install and config.wrapper. nixos outputs an activation script, and also some other things, like theres a vm output. These ones in nix-wrapper-modules are designed to be evaluated independently, or used as submodules. Whereas the nixos set of base modules are meant to be the top level of options for a machine.

[removed-user]

Oh, woops, thoughtlessly said "module system adapters", when the project is called nix wrappers modules...

What I meant was the way you're using functions/evalModules to evaluate, combine/merge them through the dag...

So, really I want the dag, and tooling to use it.

There were a few convenience adapter-esque functions on top of the dag itself.

I got a bit confused reading through the code at the point that you have derivation producing functions integrated with it, and the ordering of them.

Personally, I was interested in using the dag engine, with a mapping function, so we could add "meta-data"/tags to modules, and select module-load order functionally.

Whether that be through a number or using it's class-type to determine ordering, etc.

I'd really like to be able to have a generic "stages"/module-dependency type of attrset in a flake, in order to better apply dependency injection patterns, and prevent recursion problems in the module system.

So, for example.

Stage 1

Could be setting up nixpkgs-lib, adding any other lib components under your own top-level myLib attrset, importing any other flakes that provide library functions you want, and "locking them all down" for the rest of that evaluation.

stage 2

Could add a meta-options system, that sets an options system for functions... which extend the module/options system. To add convenience functions for boilerplate.

Basically could... literally wrap the module system with options.

Never worry again about whether using a config value in an options declaration could be a problem, since we know - that config item references something already evaluated.

We could fully resolve all _module.args, pkgs, or other arguments, wherever they're set in a stage.

All of this would just make it super easy for people to make and share their own libraries. Which is something I want to see more of.

I thought I saw a type other than just wlib.types.specWith in the dag?

[BirdeeHub]

I thought I saw a type other than just wlib.types.specWith in the dag?

It is an alias for lib.types.attrsOf (wlib.types.specWith { ... }) with data, name, before, and after fields.

This allows you to provide either a somename = value, or a somename = { data = value; before = [ ]; after = []; }

The specWith type will normalize that for you such that the result is all in the set form.

We then push the names down if the name field was not set, and then sort it with lib.lists.toposort using wlib.dag.unwrapSort

Personally, I was interested in ... ... so we could add "meta-data"/tags to modules, and select module-load order functionally.

We use the module system as-is

nix-wrapper-modules/lib/lib.nix

Lines 35 to 49 in 8dd304c

	evalModules =
	evalArgs:
	lib.evalModules (
	evalArgs
	// {
	modules = [
	wlib.core
	]
	++ (evalArgs.modules or [ ]);
	specialArgs = (evalArgs.specialArgs or { }) // {
	inherit (wlib) modulesPath;
	inherit wlib;
	};
	}
	);

.wrap .apply are just aliases for extendModules

Modifications to the module system itself are out of scope for this repository. That would require vendoring a lot more of the nixpkgs lib, and having our own lib.evalModules implementation. Part of the strength of this repository is that we do not do that, so our modules work seamlessly as submodules in other module systems.

However, we do make many custom types. specWith is the most complicated of them, but we have several more as well, some of which are quite useful. For example, wlib.types.attrsRecursive is like lib.types.anything but lists within it will be merged like the normal list type.

These are regular module system types though, they work entirely within the module system. They don't have any control over module load order.