Support for multi-root workspaces

[butaca]

The plugin does't seem to work properly with multi-root workspaces.

When having multiple .envrc files, each one in each root, it detects only one .envrc file and ignores others.

[mkhl]

What would you expect it to do instead?

[butaca]

I would expect it works exactly as it working now, but as it were N different instances of vscode, one for each root. So if I have roots a,b,c and each one having its own .envrc file, when I open a terminal in directory a, only a/.envrc is loaded, if I open a terminal in directory b, only b/.envrc is loaded, and so on.

I can achieve the same results but opening a different instance of vscode for each a, b and c but it defeats the purpose of a multi root workspace.

[mkhl]

The settings to the environment need to happen for the whole workspace so I don't think that's possible.

I'm curious though, what would you say is the purpose of a multi-root workspace?

Because to me it's having a consistent setup that happens to span several folders, and from that perspective, what you're describing would "defeat the purpose" of multi-root workspaces.

[butaca]

If you are working on a project that have several components like servers and clients for example, it makes sense to have different directories (and several repos) for each one of them and working on them separately, but sometimes you need to work on several of them at the same time if you are full stack dev, or even a solo dev. In that scenario a multi-root workspace makes sense to have the projects open in the same vscode instance instead of switching instances. In this case you would want to have a .envrc for each component, and keep this configuration when opening the multi-root workspace. If you have a single .envrc you are forced to share settings across components, leading to all kinds of issues.

[mkhl]

Interesting, thank you for sharing. I'd argue that what you're experiencing is your code trying to tell you that it wants to be either more cohesive or more independent, but this is not the place for that.

What you're asking for isn't possible with vscode, but I should document how this extension behaves and why and that this is expected.

Also have you looked at #553? I haven't managed to release it yet but you should be able to find its built extension in the PR actions. It should allow you to change which envrc should be loaded while working on a project like yours. Would that help any?

[butaca]

Thank you for developing the plugin and taking the time to evaluate this suggestion.

I'd argue that what you're experiencing is your code trying to tell you that it wants to be either more cohesive or more independent, but this is not the place for that.

That's an interesting statement given the little knowledge I have shared about my issue (which actually has nothing to do with code), but certainly it is not the place to argue about this.

553 is not ideal for my use case but helps.

Thanks again for your time.

[yangm97]

Because to me it's having a consistent setup that happens to span several folders, and from that perspective, what you're describing would "defeat the purpose" of multi-root workspaces.

From my perspective, that could easily be achieved with single-root workspaces, although it could require some clever symlinking.

What you're asking for isn't possible with vscode

Now that's what I would call a bummer.

That's an interesting statement given the little knowledge I have shared about my issue (which actually has nothing to do with code), but certainly it is not the place to argue about this.

To play the devil advocate's here it does make sense in theory. Even if you're a full-stack/solo dev you should be able to develop/prototype the frontend aside from the backend. If you have closely related microservices you should be able to stub each other's behaviors in development. Boundaries and stuff.

But it may very well be the case you're tasked with (hopefully legacy) tightly co-related projects (as in git repos). Or maybe you're a multi-tasker, possibly using gitlens workspaces feature to work on multiple branches simultaneously. Or...

I guess what we all wanted to achieve is a way to multiplex a vscode window to work with more than one "project". Given vscode is unable to keep and restore window locations because electron didn't bother implementing the relevant APIs, having each window tied to a single project, when you work on more than one company/context, the window count to manage and move across virtual desktops and whatnots, every time vscode restarts, becomes quite painful.

In my case each project has its own set of recommended extensions and these consume env vars such as PATH from direnv, and direnv uses nix flake so selecting one envrc specifically is not going to address the issue for me, but it's true that after #553 I can load a "super envrc" that loads the flakes from all projects in the workspace, at the expense of polluting PATH and other vital env vars, but that's a price to pay if vscode doesn't implement some API to keep these independent as if they were on different windows.

[butaca]

Thanks for your thoughts @yangm97

I understand and agree with you 100%. You should be able to decouple stuff, and you should do it if you can. However, some projects demand simplicity and sometimes the added complexity to do the right thing is counterproductive. I was in one of those scenarios when I suggested this feature. A multi-root project was a practical solution at that moment. ¯\_(ツ)_\/¯

[rosejn]

We run into this issue as well because we have a system composed of multiple services and projects. At least for us the only place we really run into this problem is when using a jupyter notebook inside of vscode. I think if the direnv extension just had an additional command to be able to select which .envrc you want to source that would basically solve it. Would that be feasible?

[mkhl]

I think if the direnv extension just had an additional command to be able to select which .envrc you want to source that would basically solve it.

That was contributed in #553 and is available as the "Load .envrc file" command.