nh roadmap

[NotAShelf]

Hey all! With nh 4.2.0 on the horizon I'd like to outline future goals of nh. As such I am creating this roadmap to keep track of features I'd like to work on the future and give nh users a place to request new features. This issue will be regularly updated as per user requests and based on maintainers' discretion on what to add next.

4.2.0

4.2.0 has been released, and is available in NixOS 25.11 and 26.05

• There are still a few bugs remaining in NH that need fixing. Recent PRs have managed to mostly address those, but it'd be great to close outstanding issue reports before 4.2
• Alternative privilege escalation utilities (fix: support to other privilege elevation programs. #92)

4.3.0

4.3.0 has been released, and is available in NixOS 26.05

• NixOS VM tests & snapshot tests
• Benchmarks with Criterion or similar (treewide: add hotpath for profiling allocations and timings #451)
• Implement nh home info and nh darwin info commands similar to nh os info for displaying relevant generations
• Finish treewide: refactor --build-host to use remote build semantics #497 and bring remote building capabilities on par wit nixos-rebuild/similar tools
• Various minor improvements or bugfixes
  • nh cleancheck if gcroots are opened before deleting them #60
  • DOCS: document Nix Build Passthrough flags #426
  • nh does not try to elevate privileges when called with --bypass-root-check #439
  • Recognized environment variable NIX_CONFIG wrong and called failure #440
  • --commit-lock-file flag doesn't work #512
  • Implement --profile-name instead of hardcoding /nix/var/nix/profiles/system, use /nix/var/nix/profiles/system-profiles/<name>

After 4.3.0 (4.3.1? 4.4?)

• nh os edit to open flake/configuration directory with $EDITOR. This is a part of the feature-parity section, but it's an easy task so I'd like to get it out of my way when I get the chance.
• An offline search implementation, perhaps even a search TUI featuring something like rippkgs.

Long Term

I think one of the first issues we'd like to focus on is feaure-parity with nixos-rebuild and the new nixos-rebuild-ng. I don't believe the latter is very different, but worth considering nevertheless if we strive for mass adoption of nh

• nixos-rebuild
  • switch
  • boot
  • test
  • build
  • dry-build (nh os build --dry)
  • dry-activate
  • edit
  • build-image
  • build-vm (Add build-vm subcommand to nh os build to build a VM start script. #208)
  • build-vm-with-bootloader (Add build-vm subcommand to nh os build to build a VM start script. #208)
  • Upgrade
    • --upgrade (flakes)
    • --upgrade (channels)
    • --upgrade-all
  • --install-bootloader
  • --no-build-nix, --fast (only this is supported)
  • --rollback nixos: implement rollbacks #265
  • --builders (via passthrough of options)
  • --profile-name
  • --build-host, --target-host nixos: add --target-host and --build-host options #276
    • --use-substitutes, --use-remote-sudo (nh as a deployment tool)
  • --flake
  • -I nixos-config=...

Distant Future

While not exactly a priority, there are some features I'd like to implement to extend nh's position to something beyond just a structured bash script. Namely I want to consolidate relevant NixOS-adjecent tooling into nh as subcommands.

Critical

• nh {os,home,darwin} generate-config to replace nixos-generate-config and similar HM/Nix-Darwin counterparts (are there any? Can we use flake templates instead here?)
• nh os enter to replace nixos-enter

[viperML]

@NotAShelf I've set you as the admin of the repo, let me know if it was configured properly.

[NotAShelf]

Seeems to have worked, thanks. Are you quitting working on nh entirely?

[viperML]

I see myself doing some PR for a minor feature, but NH as I envisioned it years ago is feature complete. For this reason I think it would be better to put someone else in the spotlight

[ahoneybun]

Thanks for the work everyone! I hope to be able to use it for deployment in the near future! I already use to test changes in merge requests!

[Eveeifyeve]

• An offline search implementation, perhaps even a search TUI featuring something like rippkgs.

Would something like Ratatui x crossterm work for this?

• nh os enter to replace nixos-enter

Would nh os enter have a disko mount option so it uses disko to mount before entering? Like --mount-disko?

[NotAShelf]

Would something like Ratatui x crossterm work for this?

Yes, they'd work and they are the crates I have in mind for the task. The unfortunate part is that Ratatui is... quite large. Though we are still in an acceptable threshold (if you disregard Viper's complaints ) for a Rust crate size.

Would nh os enter have a disko mount option so it uses disko to mount before entering? Like --mount-disko?

I don't use Disko, and I'm against declarative disk partitioning in general. If this gets contributed and the contributor makes a commitment to maintaining it, I might consider supporting such a feature after nh os enter has been added. Suffice to say it's a possibility, but not a goal.

[Eveeifyeve]

Would something like Ratatui x crossterm work for this?

Yes, they'd work and they are the crates I have in mind for the task. The unfortunate part is that Ratatui is... quite large. Though we are still in an acceptable threshold (if you disregard Viper's complaints ) for a Rust crate size.

But I feel it's acceptable to have this crate. Because implementing it manually requires a lot of work, a lot of time and effort that isn't really worth it/battle tested.

Would nh os enter have a disko mount option so it uses disko to mount before entering? Like --mount-disko?

I don't use Disko, and I'm against declarative disk partitioning in general. If this gets contributed and the contributor makes a commitment to maintaining it, I might consider supporting such a feature after nh os enter has been added. Suffice to say it's a possibility, but not a goal.

I will be happy to maintain this part after nh os enter has been added.

[NotAShelf]

But I feel it's acceptable to have this crate. Because implementing it manually requires a lot of work and a lot of time and effort that isn't really worth it and not battle tested.

Exactly. To my knowledge there isn't another crate that provides a better API with a smaller size, so I will most likely go with Ratatui for the TUI once offline search and option search have been implemented. The developer experience is also pretty good, so while I am concerned, I am not opposed to using Ratatui.

[Eveeifyeve]

But I feel it's acceptable to have this crate. Because implementing it manually requires a lot of work and a lot of time and effort that isn't really worth it and not battle tested.

Exactly. To my knowledge there isn't another crate that provides a better API with a smaller size, so I will most likely go with Ratatui for the TUI once offline search and option search have been implemented. The developer experience is also pretty good, so while I am concerned, I am not opposed to using Ratatui.

And not to mention I could try and implement all of the things required to switch this project to cranelift (which offers JIT Compliation). Because I am going to start heavily working on the ecosystem trying to fix a lot of issues.

Also is there a matrix channel to talk about a feature idea that I have, but I don't want to create an issue because I am not sure how I will implement it without some discussion first?