firefox: move options into profiles submodule

[0xda157]

Link: https://github.com/nix-community/stylix/issues/1651

---

• I certify that I have the right to submit this contribution under the MIT license
• Commit messages adhere to Stylix commit conventions
• Theming changes adhere to the Stylix style guide
• Changes have been tested locally
• Changes have been tested in testbeds
• Each commit in this PR is suitable for backport to the current stable branch

[0xda157]

I'm currently stuck on the below error, which doesn't make any sense:

«error: The option `virtualisation.vmVariant.home-manager.users.guest.options' does not exist. Definition values:
- In `/nix/store/a8sgh5vpac9nqszdp1ddma472ih9dmfv-source/modules/firefox/each-config.nix'»

[MattSturgeon]

I'm currently stuck on the below error, which doesn't make any sense:

«error: The option `virtualisation.vmVariant.home-manager.users.guest.options' does not exist. Definition values:
- In `/nix/store/a8sgh5vpac9nqszdp1ddma472ih9dmfv-source/modules/firefox/each-config.nix'»

This error is typically caused by shorthandOnlyDefinesConfig in submodule option types:

https://nixos.org/manual/nixos/unstable/#sec-option-types-submodule

When shorthandOnlyDefinesConfig = true (the default for types.submodule), an attribute named options is interpreted as defining an option literally called options — shorthand for config.options — rather than declaring option definitions. So if a submodule contains:

options = { … };

the module system believes you are defining the option:

virtualisation.vmVariant.home-manager.users.guest.options

which doesn’t exist, leading to the error you’re seeing.

A common workaround is to use a module form that isn’t a plain attribute set, e.g.:

• function-shaped modules:

  _: { options = { … }; }

• file-path modules (./file-module.nix)

which disable the shorthand behavior, or to use types.submoduleWith if you can control the submodule type.

[MattSturgeon]

Although, if that's a home-manager configuration, I don't think it uses shorthandOnlyDefinesConfig. IIRC.

Is Home Manager's NixOS module imported into the virtualisation.vmVariant submodule? Assuming that even is a NixOS configuration submodule?

[trueNAHO]

I did not really read the diff, but is there no way around extending the Stylix module system by using existing functionality? It would be sad to increase its complexity unless absolutely necessary.

[0xda157]

I did not really read the diff, but is there no way around extending the Stylix module system by using existing functionality? It would be sad to increase its complexity unless absolutely necessary.

I have an alternative solution which should make the diff on /stylix/mk-target.nix very small, but I don't have time to implement it this week.

[0xda157]

I've implemented the alternative solution and it basically doesn't work. mkTarget need to access to config from the top-level so as far as I can tell the only way to do it is by passing some submodule function.

[trueNAHO]

After backtracking conversations, I do not fully understand what is going on and can therefore not really help. Specifically, I do not understand how the end-user interface is supposed to change and how this should be implemented.

IIUC, the issue is that extending profile declarations with Stylix theming currently requires explicitly declaring profiles to be extended such that the following application is possible:

stylix.targets.${target}.profileNames = ["one" "two" "three"];

programs.${program}.profiles =
  lib.genAttrs config.stylix.targets.${target}.profileNames /* ... */;

1. Why can we not simply extend all submodules by iterating over them, or does this lead to infinite recursion?

2. IIUC, the proposal is also about adding top-level stylix.${target}.profiles.${profile}.enable options to potentially disable theming for certain profiles. If the already defined Home Manager submodule can be extended, would it not be better to add this option under stylix.targets.${target}.profiles.${profile}.enable or programs.${program}.profiles.${profile}.stylix.enable?

Considering all of this, why does mkTarget need to interface a "submodule"? If this is just to declare options outside the default stylix.targets.${target} namespace, then this should already be possible by declaring them inside imports.