Greater visibility into the background build process would lead to fewer surprises for lorri users

[exarkun]

Feature description

Lorri helpfully re-builds the shell derivation on demand in the background when necessary. This provides a very streamlined user experience where the work to change the shell derivation expression itself is the trigger to update the environment - rather than requiring users take an extra step after changing the expression to build and activate the expression.

However, by doing this work implicitly in the background one thing is lost - explicit notification to the user about when a build starts and stops and whether it succeeds or fails.

Lorri should preserve the best parts of both workflows and deliver this information to users about the background builds it performs.

One way Lorri could do this (eg, in bash) is to take control of part of the shell prompt and present the information there.

For example, for a prompt displayed when the current environment is considered up-to-date with respect to shell.nix, instead of the usual prompt, Lorri could arrange for the prompt to be:

[✅ exarkun@magnon:~]$

If the prompt is displayed while Lorri is performing a build:

[🏗 exarkun@magnon:~]$

And quite importantly, if a prompt is displayed after a build attempted by Lorri has failed:

[⚠️ exarkun@magnon:~]$

Of course, the unicode is cute but this information could easily be conveyed with short ASCII-only words instead. Other variations might be to display the time since the last successful build or some kind of generation counter (though I believe an explicit "something has failed, your environment is stale, it will remain stale until you fix it" indicator would be very valuable).

Target users

This will help all Lorri end-users by giving them more complete information about the state of their environment.

[nyarly]

Lorri already has a feature wherein it can report its internal state.

In my shell, I use a function based on lorri internal__stream_events --kind snapshot to determine what's happening when the prompt is rendered.

At various times, I've also run a little service that consumed the live stream (i.e. without --kind) and issued libnotify messages when builds completed.

[nyarly]

@exarhun Did that addess you issue?

[exarkun]

Nope. I was looking for something that is more of an end-user experience rather than pieces for building my own (esp. since it sounds like perhaps the pieces are there and someone just needs to assemble them for lazy folks like myself).

[sersorrel]

I use the following config block for starship, which prints a 🚛 whenever lorri's active, followed by ⌛ if it's currently building or ❌ if the last build failed:

[custom.lorri]
command = "timeout 1 lorri internal stream-events --kind snapshot | jq -r --arg pwd \"$PWD\" 'if .[keys[0]].nix_file | startswith($pwd + \"/\") then {Completed: \"\", Started: \"⌛\", Failure: \"❌\"}[keys[0]] else \"\" end' "
description = "Whether lorri has finished evaluation yet"
format = "with [$symbol($output) ]($style)"
shell = "sh"
symbol = "🚛"
when = "test -v IN_LORRI_SHELL"

though I get a log line in journalctl every time the prompt is evaluated saying INFO build status, message: NewListener(Sender { .. }), which is mildly unnerving and I wonder if it's related to #82 at all.

[nyarly]

@exarkun I think the chief problem there is that it's challenging to build an "end user experience" for developers. @sersorrel 's example is illuminating: I would not have thought to build a starship component, and while it's certainly the hot thing for prompts, I don't use it personally and would be frustrated if that were the only way to get lorri info in my prompt.

That said, we're open to design thoughts here. What would you consider "end-user" as opposed to "enough to build your own?"

[nyarly]

Immediate thoughts would be a command line "lorri status-glyph" that essentially packaged up commands like the ones we've build in shell scripts or starship configs into a neat package. Run it something like

lorri status-glyph "✔✘⏳"

and could be plugged into a PS1 or starship config.

Related, I wonder if it would also be worth building something like the notification service I run:

lorri internal stream-events --kind live |\
jq --unbuffered '(
  (.Started?   | values | "Build starting in \(.nix_file)"),
  (.Completed? | values | "Build complete in \(.nix_file)"),
  (.Failure?   | values | "Build failed in \(.nix_file)")
)
' |\
xargs -n 1 notify-send "Lorri Build"

So something like

lorri run-on-event notify-send "Lorri Build" MSG