Implement direnv "unload hooks"

@grahamc writes:

In Direnv, we'll want to be able to get an event when the shell is unloaded, for https://github.com/target/lorri/issues/32.

An important question is: can editors handle exit hooks too? This is pretty important behavior, I think. A future where lorri helps with service management could also benefit from these exit hooks.

@zimbatm writes:

Because the direnv process is only called on prompt change it makes this quite difficult to implement in a reliable manner. The user can exit or kill the shell, or exec into a different program. All of these would not trigger the unload hook.

See direnv/direnv#129 for some discussions around the topic.

@shlevy writes:

Specifically for #32, wouldn't a CLOEXEC fd handle both shell exit and execing into a different program?

@zimbatm writes:

this would imply that the fd is attached to the shell. direnv itself is only executed shortly before a prompt.

@shlevy writes:

https://github.com/taviso/ctypes.sh :trollface: More seriously I'm wondering if we can just take the hit of "you have to run your shell under lorri if you want certain features" so we can take care of any setup like this

@zimbatm writes:

direnv is not that complicated to re-implement. One route would be to have lorri shell only support bash, and re-implement a direnv-light under it. Since lorri shell would be staying around it can control the daemon liveness (and have one running per shell).

The biggest downside is that each IDE would have to be extended to support the environment live-reloading mechanism. Maybe it's Ok to only support VSCode out of the box?

@shlevy writes:

IIRC the main point of using direnv was getting multiple editors/shells supported for free.

@grahamc writes:

Yes, direnv is like a secret weapon of "how do I make this work with every editor." Thinking further, this is not a dealbreaker. We can use lorri shell for service management or something. Having a background evaluator going will do, essentially, nothing: it is just sleeping and waiting for an event from the kernel.

@zimbatm writes:

Another idea:

add a use_lorri function to the direnv stdlib. This will be a good excuse for me to introduce a mechanism to extend the stdlib.

use_lorri() {
  # select a place where to put the eval output
 local lorri_path
 lorri_path=$(direnv_layout_dir)/lorri

 # lorri would output all the files that have been used and are not in the /nix/store
 # lorri would write the eval output to "$lorri_path"
 files=$(lorri evaluate --list-mutable-files --output "$lorri_path"`)

 # load the lorri evaluation output. here it's in the .env format.
 dotenv "$lorri_path"

 # instruct direnv to reload if any of these files have changed
 for file in $files ; do
   watch_file "$file"
 done
}

target / lorri

Implement direnv "unload hooks" #33