Nixos need a replacement for nixos-rebuild!

idea.md

nixos executable

Basic features:

• installable as package, even on non-nixos
• is named nixos
• is written in C++ and binds to Nix C++ library (or maybe Haskell? Nodejs? What you think?)
• autocomplete, ncurses, Nix 2.0
• commit to Git by default on each rebuild

Subcommands

First I'll describe existing nixos-rebuild switches, that should go into new command:

• nixos-rebuild switch -> nixos rebuild, nixos rebuild --boot --activate
• nixos-rebuild boot -> nixos rebuild --no-activate
• nixos-rebuild test -> nixos rebuild --no-boot
• nixos-rebuild build -> nixos build
• nixos-rebuild dry-x -> nixos x --dry, nixos x --test
• nixos-rebuild --build-host -> nixos --build-on
• nixos-rebuild --target-host -> nixos --deploy-to
• nixos-rebuild switch --rollback -> nixos rollback opens a curses screen so you can select what to rollback to

Then, existing commands should be intergrated. All of those should work on non-NixOS:

• nixos-option X -> nixos option X
• show all options -> nixos options, the output should be compatible with FZF and fast
• nixos-generate-config -> nixos config --default, outputs to stdout
• nixos-install -> nixos install
• nixos-container XXX -> nixos container XXX
• nixos-version -> nixos -v, nixos --version. nixos -vv should be same as nix-info
• lustrate thing -> nixos lustrate --confirm-lustrate

And finally, some external projects should be merged in:

• nixos-infect -> nixos infect --confirm-infect, also nixos infect --confirm-infect --deploy-to

Anything missed?

Shouldn's nixos build rather be nixos rebuild --no-activate --no-boot? Or should the subcommand just be build for every action? Due tu the declarative nature of nix it should not matter if something is built or rebuilt, right?

Can you give a reasoning why --build-on is better than --build-host? Same for --target-hostand --deploy-to.

I don't think the rollback command should require an interactive dialog. I think good shell completion should suffice.
(A nice feature for this subcommand would be if you could give dates, git commitmessages or other fuzzy stuff to find the version you want to rollback to, this could then be interactive if ambigious, but there should be a flag to suppress interactive stuff for scripting.)

I'm also not sure if your proposed git workflow will work for everyone. My config has a lot of submodules for example, so the nixos command would also have to recurse these. A less intrusive way would be to warn if the config is in a git repository and has uncommited changes, but again, only parts of the configuration could be inside a git repository...

If it should eventually replace the current interface you would also need to check if all functionality that tools like nixops currently use the nixos-... is possible with the new nixos command.

The nixos-version command should become nixos version or even better nixos infoas with nixos --version I would expect to get the version of the nixos tool and not the currently used channels.

I'm looking forward to only using Nix 2.0 tools, so i would be happy to test this 👍

Original nixos-rebuild commands are easier to type, though :)