` and all variables will be exported. Added benefit: this
+creates a gc root (to avoid nix-shell disappearing on garbage collect)
+
+How does it evaluate in the background?
+
+
+The local lorri executable, in our case ran with `lorri direnv` (see
+[below](#how-lorri-and-direnv-integrate)), starts by adding the $PWD to a
+daemon running. The daemon uses `inotify` et al. to watch for file changes and
+potentially start an evaluation. Next time `lorri` is run by the user, it
+simply queries the daemon for results.
+
+
+How does lorri know which files to track?
+
+
+It tracks three kinds of files involved in the nix evaluation:
+1. nix files: nix-build is ran ultra verbose (`-vv`) and stderr is parsed (nix
+ files will show up as `evaluating default.nix...`).
+1. string context: nix-build is ran ultra verbose (`-vv`) and stderr is parsed (the
+ files will show up as `copying my.tar.gz...`). This applies to files copying
+ to the store with for instance `src = ./.`.
+1. imported files: When evaluating the (tweaked) shell, the builtins are
+ overriden with `scopedImports` to add tracing to `readFile` and `readDir`.
+ Stderr is then parsed.
+
+
+How can direnv run between prompts and how can it update environment variables?
+
+
+
+It makes use of the `PROMPT_COMMAND` environment variable, which is similar to
+`PS1` and run for every prompt.
+``` bash
+$ direnv hook bash # to be added to your ~/.bashrc
+
+_direnv_hook() {
+ eval "$(direnv export bash)";
+};
+if ! [[ "${PROMPT_COMMAND:-}" =~ _direnv_hook ]]; then
+ PROMPT_COMMAND="_direnv_hook${PROMPT_COMMAND:+;$PROMPT_COMMAND}"
+fi
+```
+The `_direnv_hook` is the bit that actually updates the environment variables by sourcing `direnv`'s output.
+
+
+Tell me more?
+
+
+It's important to note direnv does not keep state files; everything
+is stored in environment variables (as a gzipped JSON):
+
+
+``` bash
+$ type direnv_watches
+direnv_watches is aliased to "direnv show_dump $DIRENV_WATCHES"
+$ direnv_watches
+[
+ {
+ "Exists": true,
+ "Modtime": 1598443984,
+ "Path": "/tmp/tmp.dEfuOLyc5L/.envrc"
+ }
+]
+```
+
+
+But how...
+
+
+A `direnv watch` call will actually read the current `DIRENV_WATCHES` variable, and add the new file to be watched
+
+``` bash
+$ direnv watch bash ./foo
+
+$ eval "$(direnv watch bash ./foo)"
+/tmp/tmp.dEfuOLyc5L$ direnv_watches
+[
+ {
+ "Exists": true,
+ "Modtime": 1598443984,
+ "Path": "/tmp/tmp.dEfuOLyc5L/.envrc"
+ },
+ {
+ "Exists": true,
+ "Modtime": 1598444810,
+ "Path": "/tmp/tmp.dEfuOLyc5L/foo"
+ }
+]
+```
+
+
+watch_file implementation
+
+
+Note that `watch_file foo` is simply a shortcut for evaluating `direnv watch bash foo`.
+Since this simply updates an environment variable -- `DIRENV_WATCHES` -- the
+`.envrc` is the perfect place to do this.
+
+
+
+
+
+
+How does it know not to override i.e. `$PATH` and `$HOME`?
+
+
+The output of `lorri direnv` is actually a tad more complicated. In particular,
+it overrides the bash `declare` built-in between (1) and (2) to something like
+this:
+
+``` bash
+
+function declare() {
+ if [ "$1" == "-x" ]; then shift; fi
+
+ case "$1" in
+ "HOME="*) :;;
+ "USER="*) :;;
+ "PATH="*) PATH="$1:$PATH":;;
+ esac
+```
+
+(Remember that the evaluation root is a bash script containing `declare -x
+this; declare -x that`, and that this file is sourced in the `.envrc`)
+
+
+
+
+**DISCLAIMER:** for the sake of brevity I took some liberties when describing
+the inner workings of both lorri and direnv. The goal is for you to get a good
+enough mental model, _not_ to leave feeling like your read a 500 page
+specification!
+
+### How lorri works
+
+It simply `nix-build`s a bash script that exports all the environment variables of the
+shell, called the "evaluation root".
+
+