max / alloy

shell: give direnv a nushell hook direnv shipped in the image and did nothing. It emits no nu init for the build-time trick used on starship and zoxide to call: as of 2.35.0 its hook and export targets are bash, zsh, fish, elvish, tcsh, murex, pwsh, vim, systemd, gha, json and gzenv, and there is no sign of nu arriving. So this one is written by hand, against `direnv export json`, which is a supported target rather than a workaround and hands over the environment diff in the shape nushell already wants. Lands in the vendor autoload directory next to the generated integrations, so every integration is in one place whether it was authored or generated. Registers a pre_prompt hook and a `direnv-reload` command for use by hand after editing an .envrc. Two details the implementation turns on, both measured on nushell 0.112.2 rather than assumed: Load order is env.nu, config.nu, vendor autoload, user autoload. The autoload pass running after config.nu is what makes the hook stick, since config.nu assigns $env.config wholesale and would discard a hook registered any earlier. The Containerfile claimed the opposite order and that its reason for build-time generation was that a file written at shell start is not seen until the next shell; neither holds. The real reason is cost, and it is now written that way. config.nu's hooks block says out loud that it is a reset, so the next person to add a hook knows where it has to go. PATH is applied apart from the rest of the diff. nushell holds it as a list and direnv reports it colon-joined, so loading the diff verbatim leaves a shell whose PATH it cannot search. Verified in the image with a real .envrc: entering the directory sets the variable and prepends to PATH as a list, with the added binary executable by name; leaving unsets it, and a null from direnv removes the variable from a child process rather than passing it through empty.