Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple environment profiles (either per-session or per-window) #57548

Closed
indrora opened this issue Aug 29, 2018 · 27 comments
Closed

Multiple environment profiles (either per-session or per-window) #57548

indrora opened this issue Aug 29, 2018 · 27 comments
Assignees
Labels
extensions Issues concerning extensions under-discussion Issue is under discussion for relevance, priority, approach

Comments

@indrora
Copy link

indrora commented Aug 29, 2018

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
Copy link

vscodebot bot commented Aug 29, 2018

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

@vscodebot vscodebot bot added the extensions Issues concerning extensions label Aug 29, 2018
@indrora
Copy link
Author

indrora commented Aug 30, 2018

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

@dbaeumer
Copy link
Member

@indrora you can enables / disable extension per workspace.

@indrora
Copy link
Author

indrora commented Aug 30, 2018

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
Copy link
Member

@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

@sandy081 sandy081 added the under-discussion Issue is under discussion for relevance, priority, approach label Aug 30, 2018
@indrora
Copy link
Author

indrora commented Aug 30, 2018

  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
Copy link
Member

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
Copy link

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
Copy link

@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
Copy link

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
Copy link

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
Copy link

sketchbuch commented May 25, 2020

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
Copy link

makeway4pK commented May 25, 2020

@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
Copy link

sketchbuch commented May 25, 2020

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
Copy link

@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
Copy link

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
Copy link

@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
Copy link

kekexunxun commented May 27, 2020

image
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
Copy link

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
Copy link

@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.

@bkmeneguello
Copy link

I think the MODE (or as I call it PROFILE) is the best option. Currently we have the options Enable/Disable (Workspace), we could have the PROFILE set per project, and the profiles as a config entry, like:

"extensions.profiles": {
  "javascript": {
    "extensions.profiles.enabled": [
      "xxx.yyy",
      ...
    ]
  },
  "PHP": {
    "extensions.profiles.enabled": [
      "xxx.yyy"
    ]
  }
}

And, when a PROFILE is selected (which could not be the case, so the current behavior is de DEFAULT profile), there could exist an option in the extension menu like Enable/Disable (Profile).
This setting would be synchronized like any other and the selected profile would be kept in the project metadata.

@kekexunxun
Copy link

@bkmeneguello so far, I have to close some extension manually when I changed from PHP to Javascript or something sort like this. Whether it will be called Profile or Mode, I'd better like it will be mentioned in the feature Publish Version Notes. Experiment or not, no matters. This can be a profile, vscode config, etc. Once you configured it, VSC will enable all extensions which existed and included.

@makeway4pK
Copy link

makeway4pK commented Jun 2, 2021

While I don't think this feature will be implemented soon, is there any config file that saves the enabled/disabled states (global and workspace-specific) for these extensions?

I could write a simple parser script with a console UI to toggle the extensions by groups without needing to use the vscode UI.
I imagine this would still require vscode to reload/restart but at least it'll be quicker than toggling everything manually for each new/relocated workspace and won't need you to maintain and update separate copies of multi-purpose extensions like you have to do with the extension-dir method mentioned above by @kekexunxun.

Tag me if anyone finds where extension state info is stored. Hopefully it's in plaintext.

@kekexunxun
Copy link

@makeway4pK

I tried to use a new extension to manage other extensions.

  1. After onStartupFinished, read user workspace config extension-setting (or some other name) which has a list of extensions.
{
  "extension-setting": {
    "enabled": [
      "octref.vetur",
      "xxxx"
    ],
    "disabled": [
      "xxxx",
      "xxxx"
    ]
  }
}
  1. Ask user to decide whether to continue or not, if user's choice is no, then skip below steps
  2. Use Vscode Extension Api - vscode.extensions.all get all extensions (or workspace extensions)
  3. filter those build-in extensions
  4. Enable and Disable (Activate or Deactivate) entensions. If some of those enabled extensions are not exist, we can use command to install them. If there's no need to change, then skip step 6
  5. Reload current vscode window

The biggest problem is to provide an extension's deactivation method, it may cause other problems, will you consider about it ? @sandy081

@sandy081
Copy link
Member

sandy081 commented Jun 4, 2021

The biggest problem is to provide an extension's deactivation method, it may cause other problems, will you consider about it ?

Extension disablement is not just deactivating the extension, its contributions should be unregistered in the core. So I do not think extension can do this correctly.

@isidorn
Copy link
Contributor

isidorn commented Dec 6, 2022

Dup of #116740
You can try out Profiles in VS Code or by enabling it in VS Code stable https://github.com/microsoft/vscode-docs/blob/vnext/release-notes/v1_74.md#profiles
Feedback vert much welcome!

@isidorn isidorn closed this as completed Dec 6, 2022
@kekexunxun
Copy link

Thanks a lot. I use extension workspace solved my problem, thought it needs to be initialized when new projects opened.

@github-actions github-actions bot locked and limited conversation to collaborators Jan 27, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
extensions Issues concerning extensions under-discussion Issue is under discussion for relevance, priority, approach
Projects
None yet
Development

No branches or pull requests

9 participants