persist nix-shell instance across example steps

[warren2k]

This issue is in reference to the thaigersprint-2025 branch of eelco.

Current example of shell-session workflow

shell.nix:

let
  pkgs = import <nixpkgs> { config = {}; overlays = []; };
in

pkgs.mkShellNoCC {
  packages = with pkgs; [
    direnv
    which
    hello
  ];
}

$ echo "use nix" > .envrc
$ nix-shell
...
$ direnv allow
...
$ which hello
/nix/store/...-hello-...

Currently, the shell-session below cannot be executed successfully because it's not persisted from the previous step. The only way to make it work is to re-launch nix-shell and re-execute direnv allow, which seems unnecessarily repetitive:

$ which hello
/nix/store/...-hello-...

Desired behavior of shell-session workflow

I'd like to avoid having to specify packages in shell.nix in order to work around the fact that nix-shell instances are not persisted across example steps. I'd like to be able to use packages installed in a previous launch of nix-shell in subsequent steps of an example, like so:

shell.nix:

let
  pkgs = import <nixpkgs> { config = {}; overlays = []; };
in

pkgs.mkShellNoCC {
  packages = with pkgs; [
    hello
  ];
}

$ echo "use nix" > .envrc
$ NIX_SHELL_PRESERVE_PROMPT=1 nix-shell -p direnv which
...
$ direnv allow
...

$ which hello
/nix/store/...-hello-...

This would enable examples to better align with the flow of the documentation.

[jfly]

A design goal of the thaigersprint-2025 branch is to be REPL agnostic. That is, we shouldn't have knowledge of any specific tools our users are testing. So building something specific to nix-shell is a non-starter.

That said, I could imagine being able to annotate examples as having a "shared setup" that is used for all the other codeblocks in the example. This wouldn't be perfect (shell env vars would be dropped, for instance), but I believe it would work for the scenario described here. Would that work for you, @warren2k?

[furioncycle]

@warren2k and I have been using eelco to execute examples in nix.dev and just answering from our discussion this morning about what you said. I believe having a "shared setup" would work out for this scenario and potentially a couple of the others that we were not able to test due to this issue.