Profpatsch

> I got into the habit of using `lorri watch --once` as there is no feedback from the daemon about availability of shell. What kind of feedback would you prefer...

> Maybe this is naive, but couldn’t `lorri` notice that the shell derivation is unchanged in most cases, and not do anything? It should, by just comparing the store path...

The `root_result` call here, should be a fairly easy change: https://github.com/target/lorri/blob/200f4a2b5b1bbf9a2dd8c9b51c2cb907c7aebab3/src/build_loop.rs#L187-L195

> potential for non-unix-socket communication between Lorri processes e.g. to share a cache or something in a team. Hm, I haven’t thought about this before. That would require some more...

> Pause/resume would help. At the moment I just stop and start the service, but that stops it for all projects and it can get restarted by the socket. So...

> Perhaps another useful feature here would be to not start jobs for projects that haven't been queried in some amount of time? There’s an open issue for adding a...

> Is your thought something like pushing build loops to a per-project level? I would indeed like to clean up the architecture a little bit and make less things depend...

After talking to @curiousleo I came to the conclusion that what we probably want here is parsable internal data, but without any guarantee that the interface is going to stay...

> In the meantime, is there any information on where to look, even manually, to know either what is being watched, or what is currently on the waitlist? Not that...

> (I am surprised why I can’t just pass arbitrary options – `nix`’s `--options` flag is already quite generic, why even bother duplicating logic that’s already there?) we are already...