I suspect this works and then gets rejected by some kind of a final type check: error: The option `marker_a' was accessed but has no value defined. Try setting the option

(my attempt: https://gist.github.com/SomeoneSerge/29a9e6e10cdcd3596f865c41c7042610)

That's not a type check, that's an "empty value" stub. When an option has no definitions, its value is set to a stub that throws that error.

You're probably reading the value somewhere, e.g. using config.marker_a instead of options.marker_a, or not using removeAttrs when creating __result?

On line 45 you're defining apply which is meaningless in a module, it's a feature of options.

If you're evaluating these directly with lib.evalModules instead of using a submodule option, you can do the apply manually:

(lib.evalModules { /* ... */ }).config.__result

On line 45 you're defining apply which is meaningless in a module, it's a feature of options.

Yeah I was wondering if I misunderstood the "freeformType is an option"

Here's what I meant by freeformType is an option: https://github.com/NixOS/nixpkgs/blob/ec56f7ae8cdc39eebb8a3b4aa7a3a6365c214fb5/lib/modules.nix#L213-L227

You can set it explicitly in a submodule by defining e.g. config._module.freeformType = attrsOf str, but the module system allows a "shorthand" syntax where freeformType can be defined as a top-level attr in a module and it'll do the conversion to assigning the option for you.

Here's what I meant by freeformType is an option:

Was my second guess. Thanks for walking me through these!

Awesome!

I'd highly recommend checking the marker_a.isDefined && marker_b.isDefined case too, which I assume should be an error?

The else case where neither are defined may need some special handling too: is it an error? Is it still an error if cfg is empty?

Yes, there's a few "types" of thing in the module system:

1. configuration is the final evaluated module eval, returned by evalModules. It contains _type, options, config, type` (a submodule option-type), etc
2. module these are the "modules" the module system evaluates. Can be a long-form or short-hand attrset, a function returning one, or a file containing one.
3. options these describe the attrs that can be defined in the configuration. Declared using options.foo = mkOption {}, defined using config.foo = "value" (or the short-hand syntax foo = "value").
4. option-types these are types that options can declare they have. This is where type checking and definition merging is done.

Submodules are an option-type representing another configuration. The submodule type expects the option definitions to be modules, and it merges those modules using evalModules and uses the configuration's config as its final value.

I'm not sure. Usually merging things relates to having multiple definitions for an option, but the module system does also support merging multiple declarations for an option too, in some scenarios.

You may be able to declare options._module.freeformType = mkOption { apply = x: x; }, but IDK why you would want to do that... ?

path values only get copied to the store when used with string interpolation (e.g. "${./some/path}"). If you instead stringify them with toString, then they are not copied.

E.g.

"${./foo}"
=> "/nix/store/r1l6z113nnzx44iiqp728f50lpczp577-foo"

toString ./foo
=> "/home/matt/foo"

./foo
=> /home/matt/foo

nixos/lib/eval-config.nix
71-  pkgsModule = rec {
72:    _file = ./eval-config.nix;
73:    key = _file;

$ man configuration.nix
...
       nixpkgs.pkgs
...
           Declared by:
               <nixpkgs/nixos/modules/misc/nixpkgs.nix>

actually does pass strings around

No, but when rendering files in errors, docs, etc they are stringified using toString