Load specified envrc

[lions-tech]

Use case

Consider a project setup like this:

topdir/

docs/
docs/main.html
docs/important_pkg.html
docs/less_important_pkg.html

pkgs/
pkgs/important_pkg/
pkgs/important_pkg/.envrc
pkgs/important_pkg/important_pkg_source.ts

pkgs/also_important_pkg/
pkgs/also_important_pkg/.envrc
pkgs/also_important_pkg/less_important_pkg_source.ts

I would like to develop pkgs/important_pkg and look at the docs/important_pkg.html at the same time, because important_pkg is very complex. Also I would like to extend the documentation while developing.

Additionally I would like to switch easily between the development environments of important_pkg and also_important_pkg because those depend on each other. Unfortunately I can't use the same .envrc for both, as they need different environments.

Approach

Unfortunately direnv is only capable of loading .envrc files which are located in the current working directory. The solution is to let the user specify, which .envrc file they wish to load, and then run direnv dump in the directory of this .envrc file.

The user may specify the .envrc file via the explorer context menu. Alternatively, if the command is called from the Command Palette the user may choose the file using an OpenDialog.

The statusbar is complemented to show the name of the folder in which the .envrc is located. This is to avoid confusion with multiple development environments

Important notes

• *.md files have been complemented, but I don't know if that's enough of documentation.
• I have not added any automated tests for this feature

What do you think about this?

[mkhl]

I'm still a bit on the fence about this.
On the one hand I think this could become confusing, for example because terminals would then start by unloading the custom project environment (because its direnv is running outside the directory containing the .envrc we loaded).
But on the other I think I understand your use-case…

Have you tried using multi-root workspaces for tihs use case?
This extension will load the .envrc of the first workspace root, so you could have a workspace with pkgs/important_pkg, pkgs/also_important_pkg, and docs, and another one with a different ordering for working on the other package.
Would that help?

[lions-tech]

Have you tried using multi-root workspaces for tihs use case?

No, I haven't tried multi-root workspaces yet. Thanks for the hint.
I don't think this feature will solve my issue, as we would need a workspace file for every application we want to edit - we have more than 15 of them. Unfortunately, that makes this solution a little uncomfortable.

On the one hand I think this could become confusing, for example because terminals would then start by unloading the custom project environment (because its direnv is running outside the directory containing the .envrc we loaded).

I also observed, that the terminal unloads the custom environment, but I don't think that is a problem:

• The shell environment is only unloaded, if direnv is hooked into the shell. Even though this is probable, we can not expect it.
• The unloading of the shell environment doesn't impact the extensions, nor has it impact on the terminal environment as passed by VS Code to the shell. If the user opens a shell for which the direnv hook wasn't run, the shell keeps the environment as passed by VS Code, even if some other shell decided to unload the environment. This might be the case if the user has two shells available (e. g. zsh and bash).

[mkhl]

I did a tiny bit of cleanup and merged it.
Thank you for your contribution!