I would like to use the curated 'maximum' preset in home-manager

[tbaumann]

I have verified that this feature request has not been made before

• I have checked the issues tab, and did not find a similar feature request. I understand that my issue will be closed if it is a duplicate.

Feature Type

Other

Feature description

Not sure this is really a feature request. But it seems to me that I can't use the maximal preset in `./configuration.nix' in home manager.

I do like this preset, but I don't want to use the provided standalone package because I do want to make changes to the config via the home-manager module.

Perhaps you could expose the same preset as a module? perhaps nvf.homeManagerModules.maximal

100% chance that I'm holding it wrong though.

Alternatives

copy and paste from ./configuration.nix every now and then

Additional Context

No response

[horriblename]

not entirely sure if this is possible, the main concern is that simply setting it in the config section of the module will mean the user needs to use lib.mkForce to set any option at all. Perhaps mkDefault or pushDownDefault would avoid the issue

[tbaumann]

not entirely sure if this is possible, the main concern is that simply setting it in the config section of the module will mean the user needs to use lib.mkForce to set any option at all. Perhaps mkDefault or pushDownDefault would avoid the issue

yes, probably.

Also, of course the non-maximal/nix preset is equally valuable. It's actually what I'm using right now. 😄

[NotAShelf]

I'm going to close this as a "not planned", but only because the configuration(s) provided by the configuration.nix are not curated, and certainly not designed for downstream consumption. This has been the case for quite some time now, and has been documented in configuration.nix itself. However, I would really like to:

1. get rid of configuration.nix (which has a confusing name and place)
2. create an actually curated set of configurations to serve as examples of default packages

Currently I'm open to ideas, and a new issue/discussion surrounding the concept. It's best that we think of a new model for sharing configurations or configuration bits (i.e., per-language packages) rather than making a single reusable module like the current module.