Indicate that Lorri is done building for a project

[nyarly]

With the conversion to a single daemon, it becomes difficult to tell whether a particular project is done building, which is important for knowing what kinds of things are "safe" to do. It's reasonable to update documentation while building is happening, but not run tests, for instance.

Three separate things would be helpful for this UI:

• A status bar indicator would be helpful in this case. Such an indicator will tend to be current when a tracked file changes (i.e. it will warn in time) but lag indicating "all clear" - the user needs to "poll" it by triggering a new status update.
• A libnotify/growl/whatever notification that build is complete would cover the lag. notify-rust is a nice crate for this feature.
• A is-building subcommand for use in build scripts and tools would be helpful: having a large test suite exit early if lorri is updating dependencies would be far better than it failing late with an ambiguous error.

[nyarly]

Honestly, lorri is-building used in a prompt definition probably satisfies the first case.

It may be better to have something like an event stream socket or something for the second, and let users set up their own notifications if they'd like. Weakest level shill: https://crates.io/crates/socket-notify could be adapted to serve that purpose if needed.

[Profpatsch]

Would a plumbing command like lorri daemon stream-events_ satisfy this?

$ lorri daemon stream-events_
{ "file": "/my/project/shell.nix", "event": "started", "data": {} }
{ "file": "/my/project/shell.nix", "event": "failed", "data": { … interesting data … }  }

Then stuff like

for l in $(lorri daemon stream-events_); do
    if $(echo "$l" | jq --exit-status '.file == "/my/project/shell.nix"'); then
        echo "$l" | jq --raw-output '.event' | xargs -i {} notify-send {}
    fi
done

can be used as easy integration into status bars / scripts.

If we want to always print the current status (as opposed to just new events as they come in) first, it gets a tad more complicated to implement, but should still be doable.

cc @gilligan

[roberth]

Seems to overlap #79