Nixpkgs: Use nix 2.0 commands in nixos-rebuild

[michaelpj]

Issue description

It would be great to replace the massive wall of output with the Nix 2.0 progress indicator.

It looks relatively straightforward, but does require https://github.com/NixOS/nixpkgs/pull/37693.

[michaelpj]

Ugh, and probably https://github.com/NixOS/nix/issues/1930, since most of the uses of nix-build rely on the path going to stdout.

[xeji]

Won't this make it harder to debug errors during rebuild?

[michaelpj]

Yes, that's possible. You need to nix log the thing that was being built. We could make that easy by e.g. printing the command that we're about to execute before we execute it (or if we're being really clever, only if it fails).

[bhipple]

I find the nix 2.0 build almost unusable if you're actually developing (as opposed to just installing packages from Hydra). While it's true that you can run nix log to get the failed output after-the-fact, if you're in an interactive edit-compile-test cycle it's much more natural to get your compiler/test output interactively as it proceeds instead of waiting for it to fail and then having to run a second command once it does.

[spinus]

Won't this make it harder to debug errors during rebuild?

I guess implementing --verbose could do the job.

[samueldr]

What could happen is build a command for nix using the plugin system introduced in nix 2.0, which can have deeper integration within nix, thus hoist up important information as necessary when/if the build fails (hopefully). Instead of having nixos-rebuild be a wrapper around the nix ecosystem, the new tooling could integrate more deeply without being part of nix itself.

Caveat: I do not have any special knowledge, only superficial knowledge about the plugin system, about as much as described in the manual

Nix can now be extended with plugins. See the documentation of the plugin-files option for more details.

plugin-files
A list of plugin files to be loaded by Nix. Each of these files will be dlopened by Nix, allowing them to affect execution through static initialization. In particular, these plugins may construct static instances of RegisterPrimOp to add new primops or constants to the expression language, RegisterStoreImplementation to add new store implementations, RegisterCommand to add new subcommands to the nix command, and RegisterSetting to add new nix config settings. See the constructors for those types for more details.

Since these files are loaded into the same address space as Nix itself, they must be DSOs compatible with the instance of Nix running at the time (i.e. compiled against the same headers, not linked to any incompatible libraries). They should not be linked to any Nix libs directly, as those will be available already at load time.

If an entry in the list is a directory, all files in the directory are loaded as plugins (non-recursively).

[stale[bot]]

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
2. Ask on the NixOS Discourse.
3. Ask on the #nixos channel on irc.freenode.net.

[glittershark]

this is still important to me

[Camsbury]

Seconded!