Vscode: Multiple environment profiles (either per-session or per-window)

[indrora]

VS Code is awesome, and others have taken a liking to it as well. So much so that whole IDEs are being built on top of extensions (such as PlatformIO, vs-code-arudino, Flutter, etc.)

What this means is that I typically have VS Code open three/four times (e.g. one for PlatformIO, one for Arduino, one for Python). While it's awesome I can hotswap between them, PlatformIO makes some changes to the UI that only make sense to it (e.g. there's a virtualenv I didn't realize I was in and was wondering why Python3 sources were being interpreted as Python2.7)

There's also occasionally extensions that conflict with one another -- For instance, the PlatformIO plugin just does not play well with the Arduino plugin, both try to take over parts of the interface in different ways.

There's already setting, --extensions-dir and --user-data-dir in combination, that lets you swap what directory extensions are loaded from. I'm more asking "Can I have per-window choices of extensions?" Barring that, a simple way to declare an extension-set and fire up Code with that?

[vscodebot[bot]]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Wrong "Cannot disable extension": Arduino vs PlatformIO (#55050)
  

[indrora]

Checked: This is not simply a dupe, but a more meta-bug

[dbaeumer]

@indrora you can enables / disable extension per workspace.

[indrora]

Enabling and disabling deeply integrated extensions (e.g. platformIO) on a per-workspace basis hinders a lot of things, leaves vestigial messes that take a reload to clean up.

Let's say I have PlatformIO installed, open workspace that doesn't want it (i.e. wants the Arduino extension installed). PlatformIO has already taken up a lot of resources and has popped a tab, etc. PlatformIO then has to be rather unceremoniously removed, the window reloaded a few times, and then everything works.

I'd love to pop the pallete open and say "New Window With profile" and there, a window (even if it's a whole new instance of Code) pops with only the extensions for Arduino.

My current workaround is to use Portable Code and batch files that start the environment I need. There's a huge amount of overlap and duplicates, but I can at least fix PlatformIO causing my startup time to be in the minutes.

[sandy081]

@indrora Not all extensions are like PlatformIO extensions and an extension should not do any thing (activate, install or create files) if the opened workspace has nothing to do with that extension.

You can also disable this extension completely and enable the extension on a workspace you want? Issue with the pop up approach is that you always have to specify the extensions you want to run. But if you configure (enable/disable) extensions per workspace, the enabled extensions run in that workspace irrespective of how you opened it

[indrora]

1. I don't use workspaces very often (see: very rarely) -- I'm often working from assorted repositories which are sub-repos of other repos.
2. The extensions that cause the most problems (see: PIO) are ones which do whole-window things and inject UI. PlatformIO also adds its own workspace setup (independent of VS Code to some degree)
3. Using only a positive approach means I can't just summon up Code from wherever, I have to load up a workspace now.
4. Using workspaces to enable/disable various plugins means I'm adding dev state to my repositories. This is generally not a good idea since I'm probably going to have different ideas (and extensions!) than someone else.

The idea here would be that in your user configuration you can have

"extension.sets": {
  "default": ["ms-vscode.cpptools", "ms-vsts.team"],
  "Arduino": ["vsciot-vscode.vscode-arduino","olback.vscode-serial"],
  "python": ["ms-python.python", "mukundan.python-docs"],
  "PlatformIO": ["platformio.platformio-ide"],
  "notes": ["yzhang.markdown-all-in-one"]
}

I pull up the palette and type "Select extension profile notes" or "new window with profile notes" and boom, a new window with the extensions from the set notes and from default. Or, I could call code --extension-set arduino . and whisk the current directory into a window with the arduino stuff all set up for me, as though I had.

[sandy081]

I think you are mistaken with the term workspace here.. Every VS Code window with a folder or multiple folders is called workspace and it does not matter if it is a main repo or sub repo.

If I understand correctly, you requirement is ability to open VS Code window with a given set of extensions? If so, this can be provided from CLI and also may be as a command in Command Pallette. But out of the box support will be that you have to provide the list of extensions instead of the profile.

One can come up with an extension on top of it to provide support for profiles.

[makeway4pK]

Thanks to @sandy081 for pointing me here.
I agree with @indrora , enabling/disabling extensions by workspaces is sometimes not enough. Often we work on many projects of the same type and selecting the same extensions for each one over and over again feels stupid, especially when you're testing someone else's code on your PC.

But currently, this is mandated just because we do have projects of other types as well. (list management issues)

I know vscode isn't supposed to be a full blown IDE and I like this extensions based approach. But I think the current tools for managing extensions are not enough. Extension Packs are out there but they still dump other entries in the list. Transparency: 👍 Awesome, Readability: 😕 not so good.

At the very least, let us make folders in the extensions view, just beside 'Enabled', 'Disabled' and 'Recommended', with support for 'enable all in folder' and 'disable all in folder'

[kekexunxun]

@makeway4pK @sandy081 This feature for vscode has been questioned for almost 2years. Many issues have been closed because it‘s like another, but when you open the linked issue, you'll find out the same, closed.
If we can enable/disable extensions from config file, we may have problem when we open two folders in one vscode IDE. We have to decide which folder has higher privilege.
I suggest that if we can have a 「MODE」setting, which has different user settings, vscode settings,extensions setting. The MODE we choose will override the default vscode settings and auto install/uninstall extensions, disable/enable extensions.
The problem is that many issues mentioned the developers are using vscode for different project at one time, but there's extensions conflict.
The time I change to another project, I have to disable some extensions manually, costs me many time, sometimes I have to decide whether I should to disabled this extension or not.
Hope this feature will be able to coming soon.

[makeway4pK]

I suggest that if we can have a 「MODE」setting, which has different user settings, vscode settings,extensions setting. The MODE we choose will override the default vscode settings and auto install/uninstall extensions, disable/enable extensions.

The MODE setting is a good way of explaining the feature we're requesting.

It'd be better if they(devs) take care of this before the new Settings Sync feature is pushed to stable.
I think designing this while keeping the Settings Sync mechanism in mind would be easier than trying to integrate it later, right? Or maybe the other way around, @sandy081?

[kekexunxun]

The new Setting Sync feature is very similar to an extension "Settings Sync"(shan.code-settings-sync). I use it to synchronize my vscode setting, extensions, ...etc. But it didn't solve the problem. For example, I opened 2 vscode window, one for JavaScript, another for PHP, there comes the problem, some extensions will affect two languages, such as code intellisense. So, I wanted that the MODE setting. Developers decide what extension is including in the mode.
Imagine I have two MODE, PHP and JAVASCRIPT(Can be renamed, unique).
Seven Extensions: a b c d e f g.
MODE PHP: a b c d
MODE JAVASCRIPT: a e f
When I changed to MODE PHP, I want extensions a,b,c,d are enabled and others are disabled.
Just keep extensions in the MODE are enabled is enough.
Setting Sync is not conflict with this feature, the setting can be in a config file, and it can be synchronized to my Github gist or other place.
What do you think? @makeway4pK

[sketchbuch]

This would be great to have. I currently switch between JS/React projects and Flutter and there are a load of extensions that I need for each project type. Be great if they could be activated deactivated by workspace - with the ability to associate a workspace with one or more project types (JS/PHP/Flutter etc). Also a third group of extensions that always activated for every project type - like sort line extensions etc.

[makeway4pK]

@kekexunxun

Setting Sync is not conflict with this feature, the setting can be in a config file, and it can be synchronized to my Github gist or other place.
What do you think? @makeway4pK

I don't know about the config file but its good that it won't conflict with this.

This issue was marked 'under discussion' so let's have some.

@sketchbuch , any ideas? Something that might be unique to your workflow, how do you imagine this feature?

And @indrora , how do you use tools from both PlatformIO and Arduino i the same project? I tried and failed, too much interference between them.

[sketchbuch]

I would like to be able to associate extensions with different "technologies"/"modes" or whatever you want to call them. And then just associate a workspace with one or more technologies. Extensions can be enabled/disabled already on a workspace basis so all we need is some kind of configuration for deciding what to enable/disable. And to reduce security isssues I would maybe just enable/disable extensions not automatically install new ones - that I think should still be manually done by the user. Maybe when an extension is installed the extension editor tab updates to display a list of checkboxes for each of the technologies created by the user (flutter/js in my case) and you could just checkmark each extension that way - then no new interface needs creating to manage this configuration as the extension list already show this detail page for each extension. The only thing that would need some kind of new setting would be the names of the technologies themselves - could just be a string array.

Then vscode could just activate/deactivate extensions when you open a workspace.

If the vscode team do not want to do this, just allowing the extension API to enable/disable extensions for the current workspace only would allow third parties to create an extension to manage the "technologies" and activate/deactivate extensions upon workspaces being opened

[kekexunxun]

@makeway4pK

I don't know about the config file but its good that it won't conflict with this.

I mean the feature Setting Sync may have a config file to store something useful. Yep! It won't conflict with this.

@sketchbuch
The extension "Settings Sync"(shan.code-settings-sync) I mentioned will auto install missing extensions. It stores your settings(extensions, etc.) in you Github gist, once you changed your develop environment, install this extensions first and then it input your gist token, your missing extensions will auto isntalled. Due to security issues, we can install extensions manually. But I prefer that it will help installing automatically. This thing can be written in the config file or the time we changing to another workspace the "technologies" shows some notice to ask whether to install or not. Many ways. But the "technologies" is more important for now.

[sketchbuch]

Hi @makeway4pK , But my need isn't about syncing extensions, it is about having a consistent set of extensions for different technologies. I have about 40 workspaces at the moment about 10 for Flutter the rest JS/React. If I install a new extension for flutter development I need to disable it manually in each JS workspace when I next open it. What I want is a way to automate this, not just install extensions for a specific technology if not installed already.

[kekexunxun]

@sketchbuch
Sorry for my explaining mistaken.
My need is the same as yours.
But what I said up there is about Extensions Set and Setting Sync.
Extensions Set is the most important, then how to synchronize and auto setup between different Sets is something we can have more discussion about.

[kekexunxun]

Hi, @tfohlmeister

One workaround I found is to provide different extension-dirs as launch agurments. For example

code -n --extensions-dir ~/.vscode/extensions-platformio

will use and install extensions to ~/.vscode/extensions-platformio (instead of the default ~/.vscode/extensions) and is therefore independent from another environment. The command also forces opening a new VSC window.

You can quite easily make this work with bash aliases (e.g. alias code-pio='code -n --extensions-dir ~/.vscode/extensions-platformio')

The arrow pointed to some extensions I removed in this dir.
I tried but failed. (MacOS 10.15.4), maybe there's something wrong?

[tfohlmeister]

Hi @kekexunxun,

after more playing around I ran into inconsistency issues so I deleted my comment above. This needs more tesing for sure.
One thing I found is that you have to close all windows for the extension-dir change to actually work, otherwise the new VSC window uses the same extension dir as the existing one.

[makeway4pK]

@sketchbuch :

Hi @makeway4pK , But my need isn't about syncing extensions, it is about having a consistent set of extensions for different technologies.

Same here 😅 I was just trying to think from the devs' point of view.

The functionality of the extension 'Settings Sync' mentioned by @kekexunxun is coming to vscode natively (See: https://code.visualstudio.com/docs/editor/settings-sync) with Microsoft account or Github account as the cloud options and it is being currently previewed in the insiders release. There's some granular control over the settings/extensions you want to sync/ignore.

But there's no mention or idea of multiple sets/modes/technology-groups of extensions in its roadmap. So I suggested that this feature might be taken care of along with the big one that is already out.