<{^_^}>
target/lorri#64 (by domenkozar, 1 hour ago, open): Generalize watch to support running a command, arbitrary nix files
<domenkozar[m]>
I guess I'm looking for the word feasible :)
jtojnar has quit [Quit: jtojnar]
LnL7 has joined #nixos-dev
octe has joined #nixos-dev
<Profpatsch>
domenkozar[m]: You mean instead of shell.nix?
<Profpatsch>
Depends on which interface you want i guess
<Profpatsch>
If it’s just the file name we can certainly add an argument or option.
<Profpatsch>
We *could* do something like nix’s -E, but idk whether that’s worth it.
<domenkozar[m]>
I'm fine with a file
<domenkozar[m]>
what about command to run once it's done evaluating?
<domenkozar[m]>
Profpatsch: ^^
<Profpatsch>
Hm, good question
<Profpatsch>
We want to have a lorri daemon, so it could be solved over a socket-based pub-sub-like system.
<Profpatsch>
The problem with unix sockets is that while you can read from multiple processes, which process gets a reply is randomized.
<Profpatsch>
So round-robin.
<domenkozar[m]>
But in current design it would be much easier by just invoking a shell once it's done right?
<Profpatsch>
I guess. But I don’t know whether we want to support that now if switching to a daemon-based setup makes it infeasible later
<Profpatsch>
Hm domenkozar[m], what do you think about splitting the watcher into a plumbing command? Then you can build your own logic.
<Profpatsch>
As in, it takes a nix file, watches its dependencies and outputs a json on a line when something changes.
<Profpatsch>
Then you could do something like `for event in "$(lorri watch --json foo.nix)"; do lorri build foo.nix && echo "rebuilt because of $(echo "$event" | jq '.changed-file')"; done` or similar
<domenkozar[m]>
not sure that the reason for change in particularly interesting though
<domenkozar[m]>
maybe I can't think of use cases, but most of the time one wants to just re-evaluate
<domenkozar[m]>
and do something
<domenkozar[m]>
where that could be reinvoke nix-shell, but also something else :)
<Profpatsch>
We should definitely expose the watcher as plumbing command.
orivej has joined #nixos-dev
<gchristensen>
probably better for #lorri
<Profpatsch>
gchristensen: How can you even be awake so early :)
<gchristensen>
it is only 6:45! I've been up for nearly an hour!
<gchristensen>
was*
<gchristensen>
(I'm an early riser, which is pretty great for working with a bunch of CET night-owls)
<Profpatsch>
heh
psyanticy has joined #nixos-dev
phreedom_ has joined #nixos-dev
phreedom has quit [Ping timeout: 256 seconds]
init_6 has joined #nixos-dev
<qyliss^work>
gchristensen is just always awake AFAICT
<qyliss^work>
I'm very jealous
<gchristensen>
hehe
drakonis has joined #nixos-dev
phreedom_ has quit [Remote host closed the connection]
<Profpatsch>
yeah, that one’s gonna bite us in the ass when nix gets output hash support.
<gchristensen>
it will?
<Profpatsch>
yeah
<gchristensen>
I look forward to reading about why :)
<Profpatsch>
Because we can’t share outputs between different system attribute even if the outputs hashes are all the same .
<gchristensen>
we can't?
<Profpatsch>
I can’t get it together right now, but when I last thought through it, the sharing would be bad.
<gchristensen>
seems the output hashes being the same would result in sharing just fine, since it is the identity -- so it can't not share
<Profpatsch>
Maybe I assumed that if the input hash is different there would be no sharing in the first place, but now that I think about it that’s not really a given.
Cale has joined #nixos-dev
<gchristensen>
ah, right, the input and output hashes are decoupled here