Pipe your nix-build output through the nix-output-monitor (aka nom) to get additional information while building.
While your build runs, nom will draw something like this at the bottom of your build log:
(note that to reduce clutter nom only shows timers over 1s build or download time.)
This was an experimental fun project, which proved to be useful to quite a lot of people. The purpose of it is to write something fun and useful in Haskell. You are free and very welcome to contribute feedback, issues or PRs. I do not commit to maintain this project over a long time period but it doesn’t look like I am stopping anytime soon.
By now, nom is quite fully featured with support for nix v1 commands (e.g. nix-build
) and nix v2 command (e.g. nix build
).
Issues and pull requests are welcome at https://github.com/maralorn/nix-output-monitor.
Starting from version 2.1.0, nom uses SemVer. The versioning applies to the behavior of the executable. There are no stability guarantees for the library component in the cabal project.
If your question is not answered in this README you can ask it in #nix-output-monitor:maralorn.de on matrix or open an issue on github.
pkgs.nix-output-monitor
in the usual way. You might want to install it from nixos-unstable to get the newest version.cabal-install
and run cabal install
in the checked out repo.nix build
or nix-env
or include the flake output of this repo in your nixos config.Warning: The displayed build tree might be incomplete with new-style commands like nix build
for nix versions <2.10.
The nom
binary (starting from version 2.0) behaves as a nix
drop in, with much more colorful output, but only for the following commands:
nom build <args>
: Behaves like nix build <args>
.
nom shell <args>
: Behaves like nix shell <args>
.
nom develop <args>
: Behaves like nix develop <args>
.
The latter two commands work by calling nix shell
or nix develop
twice, the first time with overridden --run exit
and monitoring the output, the second time passing output through to the user. This will incur a performance cost by doubling eval time.
Furthermore when called via the corresponding provided symlinks, nom is also a drop-in for the following commands:
nom-build <args>
: Behaves like nix-build <args>
.
nom-shell <args>
: Behaves like nix-shell <args>
.
All aliases internally use the json-based approach (see next section) and propagate error codes. If you want nom support for other nix commands please open an issue.
nix-build --log-format internal-json -v |& nom --json
Warning: Don‘t forget to redirect stderr. That's what the &
, does.
It his highly recommended to always append --log-format internal-json -v
(or use the above mentioned aliases.) and call nom
with --json
. That will give you much more informative output.
If you are in a situation, where you can‘t use the json based nix output you can still use
nix-build |& nom
Warning: Don‘t forget to redirect stderr. That's what the &
, does.
This has the advantage to also work with other commands like nixos-rebuild
or home-manager
, where it is not trivial to pass in the --log-format internal-json -v
flag. nom will pass everything it reads through, if it does not understand it. This makes it ideal to attach it to scripts which output more then just nix
output.
Colored text will work as expected in json-mode.
In human-readable log mode you can preserve the color of the redirected text by using the unbuffer
command from the expect
package.
unbuffer nix-build |& nom
Nom tries to convey information via symbols and colors
⏵
, yellow: running builds✔
, green: completed builds⏳︎︎︎
, blue: planned builds⚠
, red: failed builds↓ ⏵
, yellow: running downloads↑ ⏵
, yellow: running uploads↓ ✔
, green: completed downloads↑ ✔
, green: completed uploads↓ ⏳︎︎︎
, blue: waiting downloads∅
: a moving average over past builds of this derivation⏱︎
: running time∑
: a summary over all packages and hostsIf you can‘t see all icons you maybe need another terminal font.
I recommend any font from pkgs.nerdfonts
e.g. "JetBrainsMono Nerd Font"
.
Also different terminals might work differently well. I recommend: pkgs.foot
.
An example with a lot of downloads:
Right now nom uses four sources of information:
.drv
files for information about the out
output path.$XDG_CACHE_HOME/nix-output-monitor/build-reports.csv
.