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.
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 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.
@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.
My use case is nix-build -A deployScript && ./result. When I replace nix-build with 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.