maralorn / nix-output-monitor

Pipe your nix-build output through the nix-output-monitor a.k.a nom to get additional information while building.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Create a nixos module

SuperSandro2000 opened this issue · comments

commented

It would be cool if there would be a nixos module which would just enable nom by creating the aliases. It could also maybe hook into nixos-rebuild.

Yeah, would be cool. Main problem is, that currently nom is not robust enough as a full drop in for the nix:

  • For most nix subcommands nom will just error out.
  • There are nix subcommands which report progress, for which nom has no support, yet.
  • I think it’s likely that nom shell can break in rare use cases (because it messes with the args the user gives), then having no way to use nix shell would be bad.

Probably there are more issues, and I am not sure if it’s worth it to fix all those.

One other point is, that I don’t know how to write such a module in a way that it actually replaces nix everywhere it’s called. It could only replace nix in the PATH and in known locations, like nixos-rebuild (for which I am uncertain if a PR would be accepted). That might break users expectations when they e.g. run nixpkgs-review which might use an absolute nix path.

commented

The module could only add a wrapper function to /etc/profile which could be turned off easily with command.

I have to confess, I don’t exactly understand what you mean with that.

commented

There are two ways how we could alias nix to nom:

  • symlink nom to nix. You could then get the old nix by using which -a nix and choose the second result.
  • create a bash function which shadows nix. With that you get the original nix with command nix.

In both cases only subcommands nom understands should be forwarded to it, everything else including when running in a none interactive shell should be handled by nix.

Somewhat related, I was toying with making a nom-rebuild command from the nixos-rebuild, but we need an equivalent to nix eval for this to work properly.

See KoviRobi/nixpkgs@308f84f then an overlay like

final: prev:
{
  nom-rebuild = (
    import
      (builtins.getFlake "github:KoviRobi/nixpkgs/308f84ff16cb962de509dc9f2333cc7ddc79aeac")
      { inherit (final) system; }
  ).nixos-rebuild.overrideAttrs (_: {
    name = "nom-rebuild";
    nix3_build = "${final.nix-output-monitor}/bin/nom build";
    nix_build = "${final.nix-output-monitor}/bin/nom-build";
  });
}

but this doesn't seem to work, I think it's because the build is being done by nix eval inside nixFlakeBuild maybe, haven't looked into this properly.

commented

I just went the easy path and patched nixos-rebuild ;)

SuperSandro2000/nixpkgs@449114c

Ah that works because it is still called nixos-rebuild and config.system.build.nixos-rebuild refers to it, my one reverts to the nix build because I've renamed it nom-rebuild and the re-exec runs the normal nixos-rebuild

@SuperSandro2000: I just went the easy path and patched nixos-rebuild ;)

Is there a way to replicate this behavior without having to build a system from a nixpkgs fork with the patched nixos-rebuild?


Since this issue is marked as help wanted, is there a clear path to completion for this? From @maralorn's initial reply, it sounds like there are some dependent issues that would need to be resolved (e.g., #109, #106, others)?

Well, the "help wanted" partially relates to the fact that I don’t know exactly how to do it.

As a rough sketch two things need to happen:

a) We need to figure out how nom should behave.
b) We need to figure out how to pass nom into nixos-rebuild.

Preferably we do this without breaking anyone's possibility to rebuild their system if nom screws something up.

Yeah, #109 and #106 are probably a step in the right direction to solve a).
b) should maybe happen in nixpkgs and not in nom.

There are obviously solutions for all of this, as various people have found one or another way to implement this for themselves. I just haven’t had the time to look into how to do this "the right way"(tm).
I would be happy about any input in that regard.

For b), that's why I created KoviRobi/nixpkgs@308f84f but it's too ugly to merge back I think. Seems like SuperSandro2000/nixpkgs@449114c solves the problem by moving "${flakeFlags[@]}" after the sub-command to nix/nom. Possibly the argument parser should support the flags before the subcommand.

flakeFlags is the following

sh -x nixos-rebuild switch
[...]
+ flakeFlags=(--extra-experimental-features 'nix-command flakes')
[...]
+ nix --extra-experimental-features 'nix-command flakes' build --out-link /tmp/nixos-rebuild.aSGRCq/nixos-rebuild '/home/rmk35/nixos#nixosConfigurations."pc-nixos-a".config.system.build.nixos-rebuild'

I suspect the problem is
https://github.com/maralorn/nix-output-monitor/blob/main/exe/Main.hs#L69
looking for build as the first element of the args-list, instead of the first non-option argument

If we could get that patched, then we could merge a simpler version of nixos-rebuild than mine into nixpkgs, which just abstracts over the nix, nix-build and nix-shell commands (probably also needs #109)

Excellent input, thanks. We can certainly fix that.