Do you think a pacman-inspired output monitor for nix could be cool?

1

Hi everyone,

I’ve started working on a small toy project this week-end, I’m curious if some people think it could appeal to others.

As I’m new to Nix(OS) I clearly remember my first interaction with nix : “Wait, no progress bar? On what was sold to me as the best package manager?”. Of course this is a bit silly but it made me search for some customization, which got me to nom rather quickly, but here again this was very different from what I was used to.

So, taking inspiration from nom, I was wondering if I could try to make some front-end to nix more appealing for someone like me who just came from Arch / Pacman.

asciicast

Do you think this is a good approach? Again, as I’m rather new to Nix I might be missing huge reasons why nix interface is what it is now.

PS: the code is a hot mess but it is always better to put it online than keeping it private for bad reasons :grimacing: GitHub - remi-dupre/pinix: Progress In Nix - Pacman inspired frontend for Nix

13 Likes
2

Uh, I kind of love it. Nice work.

2 Likes
3

I also really like it! I’m currently using something like nvd to at least see what it did but knowing what it is doing is good as well:

1 Like
4

nvd look great, that’s also the kind of information I’d love to get :+1:

5

So … I had a lot of fun making the codebase cleaner and trying to iterate on my proof of concept.

I didn’t really like how nom requires you to make aliases that pipe into it. So I instead tried the approach of making wrapper commands, so I instead built wrapper commands that should be usable as drop in replacements. For example nix becomes pix, nix-shell becomes pix-shell, …

Commands that spawn a repl also somehow work but I kinda cheated. It first spawns the underlying commands with captured output and an empty standard input. When this first instance exists it restarts the same command but with forwarded pipes :man_shrugging:

One of the things it still lacks a lot is a good README, but if your interested in testing it I tried to make it easier by packaging it in a flake (the flake output is a package, I’m pretty sure it is no the normal way of doing this, but I didn’t manage to install it in my config otherwise).

5 Likes
6

In my transition from arch to nixOS I never felt like I needed it, but now that I see your demo I want it

1 Like
7

I think the next release would be so we can install it with cargo so perhaps it needs to be on crates.io? Or at least have GitHub Release so we can just download the binaries from there.

8

You should be able to install it with cargo now, Github release seems like a good idea too :+1:

1 Like
9

This is great and looks beautiful! Well done.

I had long planned to integrate download progress into nom and as a former arch user I had a similar UX in mind.
In fact, this kind of progress reporting for downloads is only possible because of a change in Nix which I upstreamed for nom. Now you beat me to actually using it. When I encounter difficulties implementing it in nom I’ll know where to look for inspiration now. :wink:

Also the alias thing: You are completely right about the ergonomics and there actually are already wrappers like “nom-build” “nom-shell” “nom build”, etc.

3 Likes
10

I was really confused what this had to do with PacMan until someone mentioned Arch Linux :sweat_smile:

This looks great and I’ve already replaced nixos-rebuild with pixos-rebuild in my deployment scripts! One minor issue I’ve had with it so far is that, when a package has successfully been built, pinix will print the entire build logs for that package. But when the build was successful, I don’t care about the logs anymore. So it would be awesome if there were an option to only show the last line or couple of lines when a build has finished.

Still this is a great improvement over the single line output that nix has by default.

11

There’s a reason people joke about gentoo being for people who like staring at build logs.

I absolutely love this, I end up staring at nix wondering what on earth it’s doing all the time, trying to figure out if a download is taking unusually long or if it’s compiling something that I think should be being grabbed from the cache.

Even if it’s not for trying to pick up on mistakes, this is an awesome learning tool, I don’t think the average newbie understands the eval → fetch sources → build → switch process, this is a way to visually show them what’s happening behind the scenes.

Only thing I’d love to see in addition to what this already shows is a list of all the things being built concurrently, rather than a little window with not enough space to show all of it.

And of course I’m curious if you show anything for the switch part of nixos-rebuild switch, that’d be really helpful, and probably not impossible with some inspection of journalctl and maybe some upstream changes :slight_smile: