exporting variables via shellHook of mkShell doesn't seem to have any effect

This might have been triggered by a recent garbage collect. Even a direnv reload doesn't help.

~/p/g/mach-nix ❯❯❯ cat .envrc
. nix/sorri mach-nix
~/p/g/mach-nix ❯❯❯ direnv allow
direnv: loading ~/synced/projects/github/mach-nix/.envrc
sorri: looking for matching cached shell in /home/grmpf/.cache/sorri/mach-nix/v2
sorri: using cache created Mon 19 Oct 2020 02:07:00 PM +07 (701eded07fcffa8542ed4cf355fdf56f)
sorri: ERROR: no link found at /home/grmpf/.cache/sorri/mach-nix/v2/701eded07fcffa8542ed4cf355fdf56f/link
sorri: please run 'direnv allow' to reload the shell
direnv: error exit status 1
~/p/g/mach-nix ❯❯❯ direnv reload
direnv: loading ~/synced/projects/github/mach-nix/.envrc
sorri: looking for matching cached shell in /home/grmpf/.cache/sorri/mach-nix/v2
sorri: using cache created Mon 19 Oct 2020 02:07:02 PM +07 (701eded07fcffa8542ed4cf355fdf56f)
sorri: ERROR: no link found at /home/grmpf/.cache/sorri/mach-nix/v2/701eded07fcffa8542ed4cf355fdf56f/link
sorri: please run 'direnv allow' to reload the shell
direnv: error exit status 1

Hi Nicolas,

For a few years, I've been maintaining my own Direnv script based on ideas from the Nix integration page on the Direnv wiki. In the meantime, the field of projects filling this space expanded a lot (Lorri, Sorri, Nixify, for example). So I took a moment to dive into each to decide if I should continue maintaining my own, or just use something maintained by someone else.

In the process of doing that, I found differences in performance with both Lorri and Sorri. The evaluation time for these were both at times around 2x the speed of just going into a Nix shell directly. That overhead isn't as perceptible with Lorri, because it runs as a background process. But it's a more noticeable hit for Sorri, when first building out an environment.

The slowdown seems to be almost entirely due to slipping in tracing on reading files with overrides. I have a toy Haskell project I was playing around with, and just entering a Nix Shell was taking me ~30 seconds (because of some Haskell.nix-based dependencies). That's pretty bad, but at least I have caching. The first-time hit is kind of annoying, though. And if changing files frequently, this could get pretty annoying. When I switched from lightweight auto-detection (no tracing) to full auto-detection, the only file I picked up for the extra 30 seconds of evaluation was the sources.json file from my usage of Niv (that tool is great, thanks for it). Over a minute of evaluation time is pretty extreme for a toy project (granted, Nix has terrible evaluation times, and Haskell.nix only stresses that).

I don't have a PR, but hopefully I've described the problem clearly enough. But that gets to something else I was hoping to run by you.

In all this exploration, I did end up iterating on my own personal project, and though I originally had no desire to rewrite something someone else has worked on, I think this is what I have ended up doing, just to prove out all the ideas I was thinking should be implemented.

Could you have a look at this project? https://github.com/shajra/direnv-nix-lorelei. I'd really appreciate your feedback. I think it has all the functionality Sorri does. The readme file has a small writeup comparing it with prior art. The idea I wanted to play around with was calling Lorri directly, rather than copying/pasting code from that project. I think I pulled that off okay. Also I rolled in a lot of features from all the other scripts that are out there. I did, though, deviate from your approach of scaffolding projects with a script called from .envrc. My approach to installation/configuration is more along the conventional lines of installing into ~/.config/direnv/lib. I do, though, use Nix to directly tie in all the dependencies needed by the script (so users can have confidence it will work upon installation).

There's so many of these projects out there. I empathize with new users confused by yet-another-option. So if you like what you see with Lorelei, I'm curious if you'd be open to joining forces behind one project.

I think I have a preference of installing a tool like sorri globally as a library. I think you're file is very close. I just need to crop out the last call to sorri_main.

So it's not like I'm blocked or anything, this is easy enough to do.

But if you think it's a good idea, I wonder if we can make it more of an official way to install sorri as a courtesy to new users.

Would you be opposed to taking out the last call to sorri_main? And then just allowing the invocation to be done explicitly in the user's .envrc file? On that note, "sorri_main" seems like a bit of an internal name. Could we just make it "sorri" instead?

I think the instructions on the README would then be:

$ echo ". nix/sorri; sorri $(basename $PWD)" > .envrc

Is that too bad? Any suggested alternative?

https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

${SORRI_CACHE_DIR_PREFIX:-$HOME/.cache/sorri/${SORRI_CACHE_NAME}}" does not follow the spec for users may want their caches. Use $XDG_CACHE_DIR as the highest priority and fallback to $HOME after.

I'm using direnv with fish and whenever sorri detects a change and decides to re-evaluate, I'm getting:

~/p/g/mach-nix ❯❯❯ 
direnv: loading ~/synced/projects/github/mach-nix/.envrc
sorri: looking for matching cached shell in /home/grmpf/.cache/sorri/mach-nix/v2
sorri: no candidate accepted, creating manifest
sorri: building shell, this may take a while
direnv: ([/nix/store/086y8hv6ayv0y90690xbff0lxgrpi6k8-direnv-2.21.2-bin/bin/direnv export fish]) is taking a while to execute. Use CTRL-C to give up.
bash: warning: shell level (1000) too high, resetting to 1
bash: warning: shell level (1000) too high, resetting to 1
bash: warning: shell level (1000) too high, resetting to 1
... (goes on forever)

some points I'd be interested in:

• support for env vars set in shellHook: lorri [x], sorri [?]
• support for project local NIX_CONF_DIR set in .envrc: lorri [?], sorri [?]