bug: home-manager expects X11 to be set up

[RossComputerGuy]

Are you following the right branch?

• [X] My Nixpkgs and Home Manager versions are in sync

Is there an existing issue for this?

• [X] I have searched the existing issues

Issue description

I have discovered that when home-manager evaluates, modules/config/home-cursor.nix tries to do mkAliasOptionModule which requires the options to be defined. This is fine for most setups. However, the problem is that with setups which wish to use home-manager without X11. Those setups will have this error:

error: evaluation aborted with the following error message: 'Renaming error: option `home.pointerCursor.x11.defaultCursor' does not exist.'

The solution would be to add an option which checks if X11 is enabled before aliasing options.

Maintainer CC

• @polykernel
• @league

System information

- system: `"x86_64-linux"`
 - host os: `Linux 5.15.63, NixOS, 22.05 (Quokka), 22.05.2751.f11e12ac6af`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.8.1`
 - channels(root): `"expidus, nixos-22.05"`
 - channels(ross): `"expidus"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

[polykernel]

Thanks for the report. I am having some difficulty reproducing the error. It is triggered by accessing the to option in doRename

toOf = attrByPath to
  (abort "Renaming error: option `${showOption to}' does not exist.");

but I am not sure how the call is reached as x11.defaultCursor is defined unconditionally and if it isn't, the module system would fail earlier from forwarding the value of from to to which access to. Please correct me if my understanding is wrong as I am not very familiar with the module system internals.

However, the problem is that with setups which wish to use home-manager without X11.

I am a bit unclear on the differences home-manager setups without x11 make in terms of the pointerCursor module. Could you provide an example of such a setup or a minimal reproducible example for the error so I can troubleshoot further?

[RossComputerGuy]

I noticed this with my nixOS based OS, ExpidusOS. I know the error is somewhat coming from these lines and these lines. I'm not sure what a minimal example would look like but it would probably involve using home-manager via an import in Flakes but importing in a module.

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

• If this is resolved, please consider closing it so that the maintainers know not to focus on this.
• If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

• If you are also experiencing this issue, please add details of your situation to help with the debugging process.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

[polykernel]

Sorry about the inactivity, I have been busy with university for the past months. I will investigate this issue more in depth over the Christmas break.

[polykernel]

Update: I managed to reproduce this bug using ExpidusOS, it seems to be caused by the use of getSubOption in https://github.com/ExpidusOS/channel/blob/master/modules/system/default.nix#L36.

options = {
  name = mkOption {
    type = with types; str;
    description = ''
      Name of the user.
    '';
  };

  nix = options.users.users.type.getSubOptions [];
  home-manager = hmType.getSubOptions [];
};

config = {
  inherit name;
};

Setting the option home-manager to a wrapped hmType eliminates the error. This leads me to think that the error is triggered by strict evaluation of the home-manager config somewhere in the mapping from config.expidus.system.users to config.home-manager.users, however I have yet to find a minimal reproducible example in terms of purely evalModules. I still have to dig into the module system to see why this is happening.

[ncfavier]

Yeah you're really not supposed to use getSubOptions like that (in fact you're not supposed to use it at all, it's used internally to generate documentation for submodules).

The fastest route to reproducing your error is to just access (hmType.getSubOptions []).xsession.pointerCursor.defaultCursor.value. home.pointerCursor defaults to null, so this fails. I'm not sure what exactly accesses it in your scenario (a trace would be useful!), but it doesn't really matter anyway.

~Instead you'd want to remove the attrsOf in hmType and make home-manager an option with that type.~ Maybe that won't work since you're then merging those definitions into the actual home-manager definitions. Maybe types.raw would help? EDIT: it would not, see next message.

[ncfavier]

Hmm, actually I guess the culprit isn't so much getSubOptions as the fact that you're assigning an already evaluated set of options to home-manager.users.foo: your cfg.users.foo.home-manager is an output of the module system (so it has things like xsession.pointerCursor.defaultCursor = <abort>) and you're feeding it back as an input, which fails because the module system (sadly?) isn't idempotent.

What you really want is a mkAliasOptionModule between expidus.system.users.<name>.home-manager and home-manager.users.<name>, but mkAliasOptionModule doesn't really work across attrsOf like that. I think you should have a look at mkAliasDefinitions and friends (the basic idea is: instead of using config.expidus.system.users.<name>.home-manager, use mkMerge options.expidus.system.users.<name>.home-manager.definitions).

(I still think you shouldn't use getSubOptions.)

[ncfavier]

(TL;DR: not a Home Manager issue, more of a module system footgun.)

[polykernel]

Thanks for the detailed explanation @ncfavier. I must admit that I don't think I can debug the root cause of this issue as it is beyond my current understanding of NixOS, but I am still curious to learn about how this behavior (forcing evaluation of getSubOptions) occurs in the evaluation process.

[ncfavier]

getSubOptions isn't the problem as I explained in the follow-up. You're basically setting xsession.pointerCursor.defaultCursor = throw "Renaming error…";, which then gets forwarded to home.pointerCursor.x11.defaultCursor so the module system has to look at it.

I'm a bit surprised this problem hasn't shown up earlier with mkRemovedOptionModule though. EDIT: it seems like it does show up, after the mkAliasOptionModule error is resolved.

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

• If this is resolved, please consider closing it so that the maintainers know not to focus on this.
• If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

• If you are also experiencing this issue, please add details of your situation to help with the debugging process.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.