# Nixos-rebuild-ng: a nixos-rebuild rewrite

**URL:** https://discourse.nixos.org/t/nixos-rebuild-ng-a-nixos-rebuild-rewrite/55606
**Category:** Announcements
**Created:** [November 6, 2024, 3:52pm UTC](https://discourse.nixos.org/t/nixos-rebuild-ng-a-nixos-rebuild-rewrite/55606 "2024-11-06T15:52:39Z")
**Posts on this page:** 20
**Page:** 1

<div class="post-metadata">

### Author: ![k0kada](https://discourse.nixos.org/user_avatar/discourse.nixos.org/k0kada/32/12502_2.png) [@k0kada](https://discourse.nixos.org/u/k0kada)
#### Post date: [November 6, 2024, 3:52pm UTC](https://discourse.nixos.org/t/nixos-rebuild-ng-a-nixos-rebuild-rewrite/55606/1 "2024-11-06T15:52:39Z")

</div>

[nixos-rebuild-ng: init by thiagokokada · Pull Request #354029 · NixOS/nixpkgs · GitHub](https://github.com/NixOS/nixpkgs/pull/354029).

Hello folks 👋.

I am here to collect earlier feedback about the PR above, a Work-in-Progress rewrite of `nixos-rebuild` in Python. The objective is to eventually it become a drop-in replacement, but first I want to know if this is something people thinks it is a good idea before I invest more time in its development.

Below is a copy of the PR description including technical reasons in why I am using Python. By the way, to be clear, if there are people that want this in another language (e.g.: Rust looks another good option) I am all in and could close this PR, but I don’t have enough familiarity in the language to help here.

* * *

#### Opening a PR to collect early feedback before I sink more time in this. Keep in mind that while code reviews are welcome, this is not the focus for this PR yet.

The current state of `nixos-rebuild` is dare: it is one of the most critical piece of code we have in NixOS, but it has tons of issues:

- The code is written in Bash, and while this by itself is not necessary bad, it means that it is difficult to do refactorings due to the lack of tooling for the language
- The code itself is a hacky mess. Changing even one line of code can cause issues that affects dozens of people
- Lack of proper testing (we do have some integration tests, but no unit tests and coverage is probably pitiful)
- The code predates some of the improvements `nix` had over the years, e.g.: it builds Flakes inside a temporary directory and read the resulting symlink since the code seems to predate `--print-out-paths` flag

Given all of those above, improvements in the `nixos-rebuild` are difficult to do. A full rewrite is probably the easier way to improve the situation since this can be done in a separate package that will not broke anyone. So this is an attempt of the rewrite.

The language of choice here is Python. I am open to other options here, and I mostly choose Python since it is the language I am most comfortable here, but I am open for other options. Still, I think Python is a good choice because:

- It is the language of choice for many critical things inside `nixpkgs`, like the `NixOSTestVM` and `systemd-boot` activation scripts
- It is a language with great tooling, e.g.: `mypy` for type checking, `ruff` for linting, `pytest` for unit testing
- It is a scripting language that fits well with the scope of this project
- Python’s standard library is great and it means we will probably need zero external dependencies for this project. For example, `nixos-rebuild` currently depends in `jq` for JSON parsing, while Python has `json` in standard library

I am aware about the current [`switch-to-configuration-ng`](https://github.com/NixOS/nixpkgs/blob/bbdb6c9774010d3492dc7f4743c28bbd72d9d672/pkgs/by-name/sw/switch-to-configuration-ng/README.md) rewrite, however I am not sure what is the scope of that project vs `nixos-rebuild`. If the idea is just a drop-in replacement than both of those rewrites are ortogonal, since `nixos-rebuild` also includes some extra logic for e.g.: profile management. If the idea is to migrate more and more logic to `switch-to-configuration-ng` and eventually drop `nixos-rebuild`, I am happy to close this PR.

---

<div class="post-metadata">

### Author: ![Aleksanaa](https://discourse.nixos.org/user_avatar/discourse.nixos.org/aleksanaa/32/12953_2.png) [@Aleksanaa](https://discourse.nixos.org/u/Aleksanaa)
#### Post date: [November 6, 2024, 4:18pm UTC](https://discourse.nixos.org/t/nixos-rebuild-ng-a-nixos-rebuild-rewrite/55606/2 "2024-11-06T16:18:42Z")

</div>

Haven’t read your PR carefully, but there’s an attempt to add a new tool as a middle ground between old nixos-rebuild and switch-to-configuration:

> <https://github.com/NixOS/nixpkgs/pull/344407>
>
> \## Description of changes
> 
> As proposed in https://github.com/NixOS/nixpkgs/iss…ues/266290:
> 
> Introduce an "apply" script to NixOS, aimed at improving deployment processes for developers and power users. The script reduces SSH roundtrips and sudo invocations by refactoring deployment logic, moving systemd-run logic out of nixos-rebuild, and simplifying the management of the profile and actions on the target host. This change addresses limitations in nixos-rebuild and offers a more efficient backend for deployment tools
> 
> Observations and deviations from the original proposal:
> 
> \- \> initiating the installation of the bootloader
>   
> This is already done by \`switch-to-configuration\`, and that's ok.
>   
> \- \> The new apply script will be called and packaged in multiple ways:
> \> 
> \> \* The \`nixos-rebuild\` package: For applying configurations that pre-date the toplevel/bin/apply script
>   
> I have avoided this, to keep the new code path simple, devoid of conditional \`ssh\` calls.
> The equivalent code in \`nixos-rebuild\` is ok to go stale, because it is only needed for old releases anyway. We can remove that in, say, early 2026, when everyone has had more than enough time to migrate away from the unsupported releases.
> 
> \- \> \`system.build.apply\` \[...\] very optional
> 
> Not done yet, and that's ok.
> 
> \- \> \*\*Interface\*\*
> \- \> - Extra parameter that allows \`pathToConfig\` to be specified
> 
> Unnecessarily complicated, and very low value once \`apply\` can be assumed to exist in, e.g. in January
> 
> \- \> - Extra: default action \[...\] TBD \[...\] should be postponed
> 
> Not needed in this PR; feature creep; postponing
> 
> 
> 
> TODO:
> 
> \- \[x\] update documentation about \`switch-to-configuration switch\` to reflect reality (of even before this PR), and/or point to \`apply\` instead.
> \- \[x\] release note
> 
> \## Context
> 
> \- Closes https://github.com/NixOS/nixpkgs/issues/266290
> \- Closes #82851
> \- Closes https://github.com/NixOS/nixpkgs/issues/258974
> 
> \## Things done
> 
> 
> 
> \- Built on platform(s)
> - \[\] x86\_64-linux
> - \[\] aarch64-linux
> - \[\] x86\_64-darwin
> - \[\] aarch64-darwin
> \- For non-Linux: Is sandboxing enabled in \`nix.conf\`? (See \[Nix manual\](https://nixos.org/manual/nix/stable/command-ref/conf-file.html))
> - \[\] \`sandbox = relaxed\`
> - \[\] \`sandbox = true\`
> \- \[\] Tested, as applicable:
> - \[NixOS test(s)\](https://nixos.org/manual/nixos/unstable/index.html#sec-nixos-tests) (look inside \[nixos/tests\](https://github.com/NixOS/nixpkgs/blob/master/nixos/tests))
> - and/or \[package tests\](https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#package-tests)
> - or, for functions and "core" functionality, tests in \[lib/tests\](https://github.com/NixOS/nixpkgs/blob/master/lib/tests) or \[pkgs/test\](https://github.com/NixOS/nixpkgs/blob/master/pkgs/test)
> - made sure NixOS tests are \[linked\](https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#linking-nixos-module-tests-to-a-package) to the relevant packages
> \- \[\] Tested compilation of all packages that depend on this change using \`nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"\`. Note: all changes have to be committed, also see \[nixpkgs-review usage\](https://github.com/Mic92/nixpkgs-review#usage)
> \- \[\] Tested basic functionality of all binary files (usually in \`./result/bin/\`)
> \- \[24.11 Release Notes\](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2411.section.md) (or backporting \[23.11\](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2311.section.md) and \[24.05\](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2405.section.md) Release notes)
> - \[\] (Package updates) Added a release notes entry if the change is major or breaking
> - \[\] (Module updates) Added a release notes entry if the change is significant
> - \[\] (Module addition) Added a release notes entry if adding a new NixOS module
> \- \[\] Fits \[CONTRIBUTING.md\](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md).
> 
> \<!--
> To help with the large amounts of pull requests, we would appreciate your
> reviews of other pull requests, especially simple package updates. Just leave a
> comment describing what you have tested in the relevant package/service.
> Reviewing helps to reduce the average time-to-merge for everyone.
> Thanks a lot if you do!
> 
> List of open PRs: https://github.com/NixOS/nixpkgs/pulls
> Reviewing guidelines: https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#reviewing-contributions
> \--\>
> 
> \---
> 
> Add a :+1: \[reaction\] to \[pull requests you find important\].
> 
> \[reaction\]: https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/
> \[pull requests you find important\]: https://github.com/NixOS/nixpkgs/pulls?q=is%3Aopen+sort%3Areactions-%2B1-desc

However, this is reverted because it has a bug that makes nixos-rebuild fail to deploy, and is too close to the release window. But there should be another attempt to reintroduce this after 24.11.

If you want to touch this part of the logic, I strongly recommend you to discuss with @roberth , so that you may be able to get a better solution.

---

<div class="post-metadata">

### Author: ![waffle8946](https://discourse.nixos.org/user_avatar/discourse.nixos.org/waffle8946/32/27221_2.png) [@waffle8946](https://discourse.nixos.org/u/waffle8946)
#### Post date: [November 6, 2024, 4:28pm UTC](https://discourse.nixos.org/t/nixos-rebuild-ng-a-nixos-rebuild-rewrite/55606/3 "2024-11-06T16:28:42Z")

</div>

Without having read the PR yet, bash to python is an improvement, there were bugs in the past due to simply using bash, because not many people are aware of its pitfalls compared to python.

---

<div class="post-metadata">

### Author: ![k0kada](https://discourse.nixos.org/user_avatar/discourse.nixos.org/k0kada/32/12502_2.png) [@k0kada](https://discourse.nixos.org/u/k0kada)
#### Post date: [November 6, 2024, 4:29pm UTC](https://discourse.nixos.org/t/nixos-rebuild-ng-a-nixos-rebuild-rewrite/55606/4 "2024-11-06T16:29:52Z")

</div>

> [@Aleksanaa](#):
>
> Haven’t read your PR carefully, but there’s an attempt to add a new tool as a middle ground between old nixos-rebuild and switch-to-configuration:

This is interesting, but I do think this approach has some issues. For example, the `system-run` thing was mostly a hacky workaround because `switch-to-configuration` script inherits the TTY from the running shell, and this caused issues when people where switching configuration remotely via e.g.: SSH and the `network.target` restarted, causing the connection to drop and the script get stucked since it could not flush more data to stdout/stderr (at least this is my assumption).

I tried `nixos-rebuild-ng` in the same situation and this issue doesn’t happen. I got disconnected from my SSH session but the switch finished successfully. The reason I assume is because we are using `subprocess`, that doesn’t inherit the TTY, so no more need for those `systemd-run` shenanigans. Even if this is not the case I have some other ideas in how we can handle this situation better than depending in the `systemd-run`.

CC @roberth.

---

<div class="post-metadata">

### Author: ![k0kada](https://discourse.nixos.org/user_avatar/discourse.nixos.org/k0kada/32/12502_2.png) [@k0kada](https://discourse.nixos.org/u/k0kada)
#### Post date: [November 6, 2024, 4:32pm UTC](https://discourse.nixos.org/t/nixos-rebuild-ng-a-nixos-rebuild-rewrite/55606/5 "2024-11-06T16:32:42Z")

</div>

> [@waffle8946](#):
>
> Without having read the PR yet, bash to python is an improvement, there were bugs in the past due to simply using bash, because not many people are aware of its pitfalls compared to python.

Keep in mind that I don’t think reading the PR in its current state is a good use of your time, at least not right now. I only implemented `nixos-rebuild boot/switch`, and I only really tested for now `nixos-rebuild switch --flake` (that works, but I wouldn’t recommend to do so yet because I had a nasty bug earlier on that completely messed up my profile, thankfully I recovered it by running `nix-collect-garbage -d`).

I am most playing right now with:

- Making sure that the code is safe to play, e.g.: setting up `mypy` and `ruff` and make sure that the code is as safe as possible to modify
- How to organize the code in a way that this doesn’t become another unmanagable mess

---

<div class="post-metadata">

### Author: ![domenkozar](https://discourse.nixos.org/user_avatar/discourse.nixos.org/domenkozar/32/38357_2.png) [@domenkozar](https://discourse.nixos.org/u/domenkozar)
#### Post date: [November 6, 2024, 4:49pm UTC](https://discourse.nixos.org/t/nixos-rebuild-ng-a-nixos-rebuild-rewrite/55606/6 "2024-11-06T16:49:16Z")

</div>

It would be great to converge to Rust in all these, but I think Python is a lot better than bash! Good work.

---

<div class="post-metadata">

### Author: ![NobbZ](https://discourse.nixos.org/user_avatar/discourse.nixos.org/nobbz/32/7022_2.png) [@NobbZ](https://discourse.nixos.org/u/NobbZ)
#### Post date: [November 6, 2024, 4:55pm UTC](https://discourse.nixos.org/t/nixos-rebuild-ng-a-nixos-rebuild-rewrite/55606/7 "2024-11-06T16:55:56Z")

</div>

I appreciate the work done and modernization of the `nixos-*` script-suite.

Though I consider it a pity that the opportunity to extract them out of nixpkgs isn’t used.

Having them in a seperate repository might make it easier to contribute to them in the long term I think, as relevant PRs aren’t getting burried anymore under hundreds of of other PRs per day.

As much as I generally think that it doesn’t make much sense to factor out the NixOS modules out of nixpkgs, I think factoring out the related tooliing really would benefit nixos, nixpkgs, and potential contributors.

Especially as you could then assign more fine grained merge control.

Also I have to agree with Domen, standardizing **all** the tooling to a single language/runtime would be ideal, though if we should prefer rust or python or perl or gleam, I do not really care, as long as there is an agreed upon runtime, and if it is for the next iteration when all the tooling is namend `*-ng-ng`

---

<div class="post-metadata">

### Author: ![waffle8946](https://discourse.nixos.org/user_avatar/discourse.nixos.org/waffle8946/32/27221_2.png) [@waffle8946](https://discourse.nixos.org/u/waffle8946)
#### Post date: [November 6, 2024, 5:02pm UTC](https://discourse.nixos.org/t/nixos-rebuild-ng-a-nixos-rebuild-rewrite/55606/8 "2024-11-06T17:02:59Z")

</div>

> [@NobbZ](#):
>
> standardizing **all** the tooling to a single language/runtime would be ideal

relevant discussion:

> [@What is Nixpkgs preferred programming language?](https://discourse.nixos.org/t/what-is-nixpkgs-preferred-programming-language/53848):
>
> In nixpkgs in most cases have bash under the hood, but in more complex cases we use other languages: Perl (it is all over the place) Python (if I recall correctly /boot setup is written in Python) Rust (I think we have it somewhere in init, maybe for the secure boot?) Perl seems to be slowly deprecated, but what are the preferred programming languages for cases when expressing things in bash is just too complicated? I would love to see documentation on this if something like this has been de…

---

<div class="post-metadata">

### Author: ![k0kada](https://discourse.nixos.org/user_avatar/discourse.nixos.org/k0kada/32/12502_2.png) [@k0kada](https://discourse.nixos.org/u/k0kada)
#### Post date: [November 6, 2024, 5:37pm UTC](https://discourse.nixos.org/t/nixos-rebuild-ng-a-nixos-rebuild-rewrite/55606/9 "2024-11-06T17:37:19Z")

</div>

> [@NobbZ](#):
>
> Also I have to agree with Domen, standardizing **all** the tooling to a single language/runtime would be ideal, though if we should prefer rust or python or perl or gleam, I do not really care, as long as there is an agreed upon runtime, and if it is for the next iteration when all the tooling is namend `*-ng-ng`

I think I already made this clear, but I am not against someone writing this in Rust. Definitely will not be me though, since I think if I started this project as a Rust project, considering that I have no prior experience with the language, one of those things would happen:

- I will get stuck, lose enthusiasm and the project will never finish
- The end result will be bad (I think it is difficult to be worse than the original, but you never know)

So if I am to be a big contributor to this rewrite, it will be in Python just because it is the language I have more experience and it is one of the 3 big languages used in Nixpkgs for core things.

Also, I don’t think having a `*-ng-ng` is that bad either. The current state of `nixos-rebuild` (I welcome anyone that is in this thread to open the original code and try to understand what is happening) is bad enough that even if the code was rewritten in Bash itself it could be improved a lot. So if this rewrite cleared up the code enough that someone got enthusiasm to rewrite this in Rust, for example, it would already do its job.

---

<div class="post-metadata">

### Author: ![roberth](https://discourse.nixos.org/user_avatar/discourse.nixos.org/roberth/32/5488_2.png) [@roberth](https://discourse.nixos.org/u/roberth)
#### Post date: [November 6, 2024, 6:10pm UTC](https://discourse.nixos.org/t/nixos-rebuild-ng-a-nixos-rebuild-rewrite/55606/10 "2024-11-06T18:10:48Z")

</div>

The `apply` script won’t be a problem for a `nixos-rebuild` reimplementation. More than anything it is a bottom-up improvement to give a better interface to the `toplevel`, such that the operations on `toplevel` are self-contained. The benefits aren’t limited to `systemd-run`; also the management of the profile link is taken care of, and it improves the architecture / separation of concerns.

Specifically it simplifies the interface between the deployable operating system (`toplevel`) and deployment tools such as `nixos-rebuild`, especially when support for the “legacy” non-`apply` code path can be dropped from such tools.  
All improvements to the “local” part of the `switch` operation can be decided by NixOS and picked up by any deployment tool. This includes swapping out `systemd-run` for something better, if it turns out we were mistaken.

Speaking of mistakes, the mistake I made in `nixos-rebuild` in [NixOS `apply` script by roberth · Pull Request #344407 · NixOS/nixpkgs · GitHub](https://github.com/NixOS/nixpkgs/pull/344407) was a simple logic inversion (`-n` vs `-z`) that I didn’t spot, and wasn’t sufficiently tested, so your effort to better test the rewrite is much appreciated.  
I expect that we can merge a fixed version after branch-off without much trouble and we might even end up backporting the `apply` script; maybe even the `nixos-rebuild` improvement as well.  
`nixos-rebuild-ng` can implement this change at its own pace, because the addition of `apply` is not a breaking change.

* * *

Regarding `systemd-run`, one of the goals is to persist into journald all logs that are produced as part of the switching operations.  
The fact that some activations may succeed despite a broken SSH connection doesn’t mean that all of them will. For instance, if they log more, they may receive a SIGHUP.  
It solves a real problem, using an appropriate tool (a transient systemd unit), so no “shenanigans”.  
I’m happy to discuss alternative ways to make it more robust.

---

<div class="post-metadata">

### Author: ![roberth](https://discourse.nixos.org/user_avatar/discourse.nixos.org/roberth/32/5488_2.png) [@roberth](https://discourse.nixos.org/u/roberth)
#### Post date: [November 6, 2024, 6:22pm UTC](https://discourse.nixos.org/t/nixos-rebuild-ng-a-nixos-rebuild-rewrite/55606/11 "2024-11-06T18:22:02Z")

</div>

Regarding Rust vs Python, I’d favor Python for a small tool like this. `nixos-rebuild` wouldn’t benefit from Rust’s low level capabilities or its extra capable type system; in fact, those may slow most contributors down.

If we have an overriding reason to switch to Rust, that can be done later. I’m not opposed to “converge on Rust” but “convergence” should’t be the only reason.  
I don’t think anyone is disagreeing about Python being good for this btw. 🚀

---

<div class="post-metadata">

### Author: ![k0kada](https://discourse.nixos.org/user_avatar/discourse.nixos.org/k0kada/32/12502_2.png) [@k0kada](https://discourse.nixos.org/u/k0kada)
#### Post date: [November 6, 2024, 8:35pm UTC](https://discourse.nixos.org/t/nixos-rebuild-ng-a-nixos-rebuild-rewrite/55606/12 "2024-11-06T20:35:33Z")

</div>

> [@roberth](#):
>
> Regarding `systemd-run`, one of the goals is to persist into journald all logs that are produced as part of the switching operations.  
> The fact that some activations may succeed despite a broken SSH connection doesn’t mean that all of them will. For instance, if they log more, they may receive a SIGHUP.  
> It solves a real problem, using an appropriate tool (a transient systemd unit), so no “shenanigans”.  
> I’m happy to discuss alternative ways to make it more robust.

Fair enough. Since this is going to be moved to this new `apply` script anyway I will not reimplement the `systemd-run` logic for activations in the rewrite.

---

<div class="post-metadata">

### Author: ![bjornfor](https://discourse.nixos.org/letter_avatar_proxy/v4/letter/b/f475e1/32.png) [@bjornfor](https://discourse.nixos.org/u/bjornfor)
#### Post date: [November 7, 2024, 7:16am UTC](https://discourse.nixos.org/t/nixos-rebuild-ng-a-nixos-rebuild-rewrite/55606/13 "2024-11-07T07:16:49Z")

</div>

Has it been explored to move as much as possible of the logic out of `nixos-rebuild` and into `switch-to-generatation`/`apply`? I have a feeling that’s a good idea, but I know too little 😄 Thoughts?

---

<div class="post-metadata">

### Author: ![k0kada](https://discourse.nixos.org/user_avatar/discourse.nixos.org/k0kada/32/12502_2.png) [@k0kada](https://discourse.nixos.org/u/k0kada)
#### Post date: [November 7, 2024, 9:37am UTC](https://discourse.nixos.org/t/nixos-rebuild-ng-a-nixos-rebuild-rewrite/55606/14 "2024-11-07T09:37:21Z")

</div>

`nixos-rebuild` has much more logic that wouldn’t make sense to move to `apply` script, for example the whole remote builder/deployment part (to be fair, it is not something that I will reimplement in the first version of `nixos-rebuild-ng` since this will take some effort).

---

<div class="post-metadata">

### Author: ![k0kada](https://discourse.nixos.org/user_avatar/discourse.nixos.org/k0kada/32/12502_2.png) [@k0kada](https://discourse.nixos.org/u/k0kada)
#### Post date: [November 7, 2024, 7:32pm UTC](https://discourse.nixos.org/t/nixos-rebuild-ng-a-nixos-rebuild-rewrite/55606/15 "2024-11-07T19:32:12Z")

</div>

I was taking a look at the code from `nixos-rebuild` to [build/bootstrap `nix`](https://github.com/NixOS/nixpkgs/blob/9d4343b7b27a3e6f08fc22ead568233ff24bbbde/pkgs/os-specific/linux/nixos-rebuild/nixos-rebuild.sh#L521-L570) and… Does it even make sense nowadays?

From what I understand reading the code, the idea is to bootstrap a newer version of `nix` because the code inside `nixpkgs` can include Nix code that is only supported by newer versions, but we also have this policy for a long time where code inside `nixpkgs` should be compatible with Nix 2.3, so I imagine this is one of those piece of code that made sense someday in the past and nowadays it doesn’t.

Keep in mind that `nixos-rebuild-ng` will always build with a reasonable up-to-date version of Nix, since I added this as a `buildInput` and this is wrapped inside the binary, so as long we suddenly doesn’t jump to the newest version of `nix` it should be fine.

Anyway, I will probably put this in very low priority to reimplement for now.

---

<div class="post-metadata">

### Author: ![k0kada](https://discourse.nixos.org/user_avatar/discourse.nixos.org/k0kada/32/12502_2.png) [@k0kada](https://discourse.nixos.org/u/k0kada)
#### Post date: [November 8, 2024, 10:45am UTC](https://discourse.nixos.org/t/nixos-rebuild-ng-a-nixos-rebuild-rewrite/55606/16 "2024-11-08T10:45:21Z")

</div>

Opening the PR for review. This should be a good first version since it has most of the basic features implemented and can be used to manage your system (with caveats, see the warning below). Also, it should have enough for other people to look at the code and start hacking (help is welcome to implement the remaining features, especially the remote part).

Of course there are lots of things to do yet:

- Missing features: [nixos-rebuild-ng: init by thiagokokada · Pull Request #354029 · NixOS/nixpkgs · GitHub](https://github.com/NixOS/nixpkgs/pull/354029#issuecomment-2461039842)
- Port our current `nixos-rebuild` tests to `nixos-rebuild-ng`
- Documentation
- Changes to the module system to allow people to opt-in for the changes
- Migration plan?

However this is still a good step. It is possible to use it as-is, so for early adopters that want to test and report issues I think this a good start. You need to understand the limitations though:

- For now we will install it in `nixos-rebuild-ng` path by default, to avoid conflicting with the current `nixos-rebuild`. This means you can keep both in your system at the same time, but it also means that a few things like bash completion are broken right now
- `_NIXOS_REBUILD_EXEC` is **not** implemented yet, so different from `nixos-rebuild`, this will use the current version of `nixos-rebuild-ng` in your PATH to build/set profile/switch, while `nixos-rebuild` builds the new version (the one that will be switched) and re-exec to it instead. This means that in case of possible bugs the only way that you will get them is after you switch to a new version
- `nix` bootstrap is also **not** implemented yet, so this means that you will eval with an old version of Nix instead of a newer one. This is unlikely to cause issues, because the build will happen in the daemon anyway (that is only changed after the switch), and unless you are using bleeding edge `nix` features you will probably have zero problems here. You can basically think that using `nixos-rebuild-ng` is similar to running `nixos-rebuild --fast` right now
- Ignore any performance advantages of the rewrite right now, because of the 2 caveats above
- `--target-host` and `--build-host` are not implemented yet and this is probably the thing that will be most difficult to implement. Help here is welcome
- Bugs in the profile manipulation can cause corruption of your profile that may be difficult to fix, so right now I only recommend using `nixos-rebuild-ng` if you are testing in a VM or in a filesystem with snapshots like btrfs or ZFS. Those bugs are unlikely to be unfixable but the errors can be difficult to understand. If you want to go anyway, `nix-collect-garbage -d` and `nix store repair` are your friends

---

<div class="post-metadata">

### Author: ![k0kada](https://discourse.nixos.org/user_avatar/discourse.nixos.org/k0kada/32/12502_2.png) [@k0kada](https://discourse.nixos.org/u/k0kada)
#### Post date: [November 16, 2024, 2:13pm UTC](https://discourse.nixos.org/t/nixos-rebuild-ng-a-nixos-rebuild-rewrite/55606/17 "2024-11-16T14:13:09Z")

</div>

The first PR is merged 🎉: [nixos-rebuild-ng: init by thiagokokada · Pull Request #354029 · NixOS/nixpkgs · GitHub](https://github.com/NixOS/nixpkgs/pull/354029).

Inviting people to test once [this hit the unstable branches](https://nixpk.gs/pr-tracker.html?pr=354029). It should be as easy as adding `environment.systemPackages = [pkgs.nixos-rebuild-ng];` to your configuration. Please also read the [README](https://github.com/NixOS/nixpkgs/blob/a895a13b5404b4059d51a06d190249e3dcb1a45c/pkgs/by-name/ni/nixos-rebuild-ng/README.md) before starting.

It would be nice to have both Flake and classic Nix users as testers, especially the later because I have no system using classic Nix.

I am also starting to work in the second PR: [nixos-rebuild-ng: improvements by thiagokokada · Pull Request #356468 · NixOS/nixpkgs · GitHub](https://github.com/NixOS/nixpkgs/pull/356468). My objective here is to implement the remaining missing features, especially the `--target-host` and `--build-host` and the `_NIXOS_REBUILD_EXEC`. After finishing those 2 features I think all features will be implemented and it will be mostly figuring out how to test this and rollout for users gradually.

It would be nice to have this ready as a opt-in for 25.05 and having this as the default for 25.11, targeting a removal of `nixos-rebuild` in 26.05, but let’s see.

---

<div class="post-metadata">

### Author: ![nyanbinary](https://discourse.nixos.org/user_avatar/discourse.nixos.org/nyanbinary/32/11523_2.png) [@nyanbinary](https://discourse.nixos.org/u/nyanbinary)
#### Post date: [November 16, 2024, 2:14pm UTC](https://discourse.nixos.org/t/nixos-rebuild-ng-a-nixos-rebuild-rewrite/55606/18 "2024-11-16T14:14:55Z")

</div>

Curious what made you decide to choose Python over Rust (like the switch-to-configuration-ng)?

---

<div class="post-metadata">

### Author: ![k0kada](https://discourse.nixos.org/user_avatar/discourse.nixos.org/k0kada/32/12502_2.png) [@k0kada](https://discourse.nixos.org/u/k0kada)
#### Post date: [November 16, 2024, 2:19pm UTC](https://discourse.nixos.org/t/nixos-rebuild-ng-a-nixos-rebuild-rewrite/55606/19 "2024-11-16T14:19:00Z")

</div>

> [@nyanbinary](#):
>
> Curious what made you decide to choose Python over Rust (like the switch-to-configuration-ng)?

The reason is in the OP and also in the README (and also in other posts in this thread) so it doesn’t make sense to repeat here.

---

<div class="post-metadata">

### Author: ![pyrox](https://discourse.nixos.org/user_avatar/discourse.nixos.org/pyrox/32/29763_2.png) [@pyrox](https://discourse.nixos.org/u/pyrox)
#### Post date: [November 16, 2024, 8:17pm UTC](https://discourse.nixos.org/t/nixos-rebuild-ng-a-nixos-rebuild-rewrite/55606/20 "2024-11-16T20:17:20Z")

</div>

This is some very exciting work to see merged! With perlless activation becoming more of a thing with switch-to-configuration-ng, perlless `install-grub`, and now this, NixOS is really becoming much more modern. This is amazing work to see.

[Next page](https://discourse.nixos.org/t/nixos-rebuild-ng-a-nixos-rebuild-rewrite/55606.md?page=2)