I would like to tell you all about the nix-output-monitor (nom in short). It is a small project I wrote on a few weekends to have a little fun with Haskell.
What does it do? You pipe the output (specfically stderr) of any nix-build (v1 command) into nom like so:
nix-build |& nom
Then nom parses the output and enriches it with a lot of cool emojis and some useful information about the build you are running.
At this point I consider the project kinda feature complete. In the sense that there is not much I feel I would like to add and it works quite stable. (But I am of course open to contributions.) It only works for the old nix commands and I hope that it will be obsolete sooner than later by the beautiful new output Eelco is working on for future nix versions.
But until then I noticed that quite a few people in the community have tried nom and quite liked it, so I wanted to share it with everyone else.
It’s super easy to install and use since it’s already packaged on nixos-unstable. Try it out if you want and tell me how you like it. You can find more infos in the README.
I reckon I’ll start using this, since the nix progress PR is getting very stale and this actually seems better imo
This seems not very charitable to me. nix development is bottle-necked by the fact that there are only a few people working on next generation nix for a large community with a lot of expectations. That PR from what I can tell only affects new-style commands like flakes, which are not even released in stable nix. So merging that PR would not even affect the commands that nom is used for. nix 3 seems to be quite a beast with a lot of fundamental changes. From the fact that there was not much action in that PR recently, which may well qualify as “polish” I don‘t think there is any reason to assume it will never happen.
Regarding “this actually seems better” I am glad you like it. Though there are certain features in that PR that I personally really like and that are very hard or even impossible to get working in nom. As written in the readme, I‘d be super happy if some ideas from nom would inform future improvements in nix.
This looks very nifty - it just makes me wonder. Surely nix-daemon either has this information or would be able to easily track it without having to resort to text parsing. How about making nix-daemon expose this information in a structured manner (JSON) which would even make it possible to query this information remotely?
I understand your reason for doing this and do not in any way want to rain on your parade - this is pretty cool.
I know, talk is cheap…
The information is already part of the Nix remote store protocol (it sends
stopActivity messages), but you would need a full client.
The screen recording of this looks pretty nifty! I’m kind of surprised you don’t just bundle a
nom-build script that looks like
nix-build "$@" 2>&1 | exec nom
Does nix-output-monitor support
nix build and flakes?
Currently not but I think it is on maralorns to do list.
I am sorry @Sandro but that is not true. It’s explicitly not on my todo list. (And I tried to say so before.)
None of the output formats of
nix build or
nix flake are easy to parse with noms current parser. The only output which actually contains all the informations needed and does not go crazy with cursor control codes is the
internal-json format. Besides the point that I don‘t like to interface with something explicitly called
internal nom would then need to reproduce the log which nix would normally produce.
Seeing that there is the open PR against nix to improve it’s output for flakes a lot I don‘t intend to invest the considerable engineering effort.
It’s definitely nice to have this tool!
I have to do a shameless plug though: @Kloenk and I created a patch that changes the Nix v2 output to be a lot like this. progress-bar: multiple output lines by Kloenk · Pull Request #3972 · NixOS/nix · GitHub
The nom-build script exits with code 0 even when the nix build failed.
@petabyteboy Have you noticed in which cases? I can describe what I think nom-build does right now and you can tell me if it fits your observations:
nom-build execs into nom. So I thought it should have the exit code of nom. nom itself exits with success in all but two cases 1) it encountered an internal error 2) it has parsed a failed build from the nix output.
One particular case were this produces potentially unexpected behavior is with eval errors. nom does not recognize them at all and therefor will merrily exit with a success.
set -eo pipefail is needed.
Yeah, that would do the job.
My use case is
nix-build -A deployScript && ./result. When I replace
nom-build, there is a previous result symlink and I produce an eval error, it will run the previous script instead of failing, which is very unexpected.