I split off my nixos option command from the nixos-cli project that I’ve been working on and made it work with pretty much any module system you can get your hands on.
As such, you can search through and evaluate options for NixOS, nix-darwin, home-manager, and flake-parts: basically, as long as you have an options attribute set exposed somewhere, you can search through those options and preview their values.
There’s a few linked recipes for how to setup the configuration file for proper searching; try it out and see how you all like it!
This is cool! Gonna try it out. Regarding HM options when using the NixOS module, it seems nixosConfigurations.HOSTNAME.options.home-manager.users.type.getSubOptions [] gives an attrset of HM options, similar to nixosConfigurations.HOSTNAME.options. Not sure if this is useful, as my knowledge of the language and module system is still pretty basic.
Interestingly I’m unable to evaluate the result from this using lib.optionAttrSetToDocList, but if you can get a good minimal example working, since you can plugin any command for generating the option list, I’d love to include in my recipes in the README! I’ll also experiment around with this for a bit on my own.
Something that would be super nice is a gif of the CLI in action in the readme. I am less likely to bother going through required (reasonable!) setup if I don’t know what my destination is.
Fair enough. I added a small GIF to the README to showcase functionality and am in the process of getting a more full-fledged docs site up soon for it.
I finally got around to installing this. It’s pretty fun! Thanks for making it. I am having a few infelicities with generating my own home manager options set, but I don’t think that’s a flaw of the tool, mostly end user error I’m currently using the following to generate my nixos settings at build time using npins / home-manager (I realised after the fact that you have a nicely packaged module in the flake, I’ll play with that later).
Ah yeah there’s a ton of different ways that you can structure this sort of thing.
However, one of the more cool things about optnix is that its configurations can be merged together, so I’d recommend configuring the NixOS option list at the NixOS level, rather than the home-manager level, unless you want your NixOS options list to be available on non-NixOS hosts. The only example I have of this is my personal home-manager configuration for optnix, but it uses flakes, so adapting it to npins or legacy-style configurations will depend on your setup.
Also, it has some problems; right now, generating the home-manager options list can be pretty flaky depending on the module since some out-of-tree modules (i.e. sops-nix rely on NixOS options being set sometimes, so they cannot be evaulated with the options list generation functions I’ve created). But that’s specifically for home-manager options lists, nothing else.
Highly recommend using my various modules + library for this; for right now it’s undocumented, but when I have time I’ll finish creating a docs website with some much better examples. I’ll try to upstream them to nixos/nix-darwin/home-manager as well, have a PR in the making putting optnix itself into nixpkgs already.
I run home-manager stand-alone (on nixos), because I hate myself I’m currently failing to generate options because of this
❯ nix-instantiate --eval --expr --strict 'let pkgs = import <nixpkgs> {}; configuration = "/home/ben/.config/home-manager/home.nix"; sys = import <home-manager/modules> { inherit configuration pkgs; }; in pkgs.lib.optionAttrSetToDocList sys.options'
error:
… while evaluating the attribute 'default'
at /nix/store/wfi1wz6ffhfkmwg19byhgdsi20dlsld4-source/lib/options.nix:592:13:
591| // optionalAttrs (opt ? defaultText || opt ? default) {
592| default = builtins.addErrorContext "while evaluating the ${
| ^
593| if opt ? defaultText then "defaultText" else "default value"
… while evaluating the default value of option `accounts.email.accounts.<name>.maildir.absPath`
… while evaluating a branch condition
at /nix/store/wfi1wz6ffhfkmwg19byhgdsi20dlsld4-source/lib/options.nix:658:5:
657| v:
658| if v ? _type && v ? text then
| ^
659| v
… while evaluating the option `accounts.email.accounts.<name>.maildir.path':
(stack trace truncated; use '--show-trace' to show the full, detailed trace)
error: The option `accounts.email.accounts.<name>.maildir.path' was accessed but has no value defined. Try setting the option.
I saw that you have some interesting code around pruning what gets indexed, I’ll poke later. I kind of feel in my bones like this is also an hm bug, but I haven’t had time to dig into the option defs yet.
Ahhh…yeah home manager does NOT like getting evaluated without _module.check = false being set, as well as a few other things. That’s why I made a small library in the optnix repo to generate option lists.
You can probably create the list like this (assuming you’re using the repo with commit cd3b780, tried to adapt it to your setup you linked from before):
{
config,
lib,
pkgs,
sources,
options,
...
}: let
optnix = import sources.optnix {inherit pkgs;};
optnixLib = optnix.mkLib pkgs;
in {
imports = [
optnix.homeModules.optnix
];
programs.optnix = {
enable = true;
settings = {
scopes.home-manager = {
description = "home-manager configuration options";
options-list-file = optnixLib.mkOptionsList {
inherit options;
# You may or may not need this depending on whether or not you use HM
# standalone vs. through an OS-level module
# transform = o:
# o
# // {
# name = lib.removePrefix "home-manager.users.${config.home.username}." o.name;
# };
};
evaluator = "";
};
};
};
}
Also, I think you need to use a fairly recent version of HM for this, I tend to update my projects frequently to follow the nixpkgs-unstable branch.
Small announcement: I’ve created a high-level documentation website with more examples and explanations for how things work in optnix. I’ll also be creating a man page for offline access.