Feature Request: Enable/disable extensions from config file

[michaeljota]

• VSCode Version: 1.18.1
• OS Version: Windows 10 FU

Explain:

There are certain extensions that play well together, and it would be useful to be able to set a config file to enable and disable certain extensions in that workspace. This would be a config file, like the extensions recommendations, but with a series of parameters that would allow to enable and disable certain extensions.

This would be like a config file for the "[Dis]Allow (Workspace)" setting.

[ThimoDEV]

As far as I can see it only works one way right now? The recommended setting in extenions.json only pops up if extensions are not installed. Having an extension disabled doesn't show a popup or auto enabled it again, or am I missing something?

[IronGeek]

As far as I can see it only works one way right now? The recommended setting in extenions.json only pops up if extensions are not installed. Having an extension disabled doesn't show a popup or auto enabled it again, or am I missing something?

I can confirm this behavior. Having recommended extensions setting is useless if the extension is ALREADY INSTALLED BUT DISABLED. I wish it would at least show a popup to enable the recommended extensions.

And IMO, this whole extension disabling/enabling feature should be handled in vscode core, not delegated to yet another extensions. Having an extension to disable/ enable another extensions is too meta...

[Cyclodex]

I completely agree @IronGeek , I just created the extension, because there is no better way right now. IMO it should be handled well and correctly in VSCode itself. Extensions are limited anyway in handling other extensions.

[TonyGravagno]

Friends: This ticket is to Enable/disable extensions from config file. One of the original suggestions was to use the new Profile feature to do this, but the first production implementation of .code-profile did not include adequate data for the purpose of this ticket. So I created a separate ticket - if profiles are really the solution, that ticket was intended to drive discussion about this specific functionality in profiles.

After many exchanges with @sandy081 who has been very patient with me and the discussion process, it looks like there is significant forward motion on this.

From this recent https://github.com/microsoft/vscode/issues/170916#issuecomment-1474478497 and following, there was a flurry of activity and Sandy implemented changes that might put this all to rest.

But! This is for You to decide. This is not an announcement (per Sandy's request). This is an invitation to you to check out the notes and provisional implementation, and comment on whether you believe this addresses your needs as we've discussed in this thread.

Please see the discussion there, where I've documented a number of use cases, and try to comment succinctly if you believe the proposed (and coded) solution does/should in fact provide the tooling we have been asking for. Let's try to be as focused as possible, not asking for anything more than the specific feature described here. If the scope of the challenge is expanded we probably won't get a solution to this one challenge for yet another five years. 😁

Summary: As discussed and hopefully implemented, the .code-profile file should now include the list of enabled and disabled extensions and their current state. This allows us to "Enable/disable extensions from config file". A system loading the profile will enable and disable the extensions so that the target matches the source in this regard.

The format of the .code-profile file has not changed and is still not user-readable. We still need a dedicated extension or a separate dedicated app to modify these files, as discussed in this thread and elsewhere. But at least now we should have the data we need in that file so that we can do the manipulation we've discussed here ... OR because the data is now in the profile we might not need to do a lot of the manipulation that we've felt was necessary here.

Again:

• This is not an announcement of a verified solution.
• Please comment on the proposed code changes if you can.
• Please try the new functionality if/when it hits beta, and let's not pressure devs for anything beyond the normal cycles.

I will be looking forward to a beta myself, pending your comments.

Thanks for your time.

[IronGeek]

Leaving my two cents here.

It's great that .code-profile finally support extension enablement.

But I still think that VS Code should have support to enable/ disable extensions from an external-user-readable-and-writable config file (my vote is on .vscode/extensions.json), that I could easily commit/ and push to a repo along with my project and automagically recognized and applied by VS Code (no need for export/import)

As to not cause conflict with the current state of .code-profile, VS Code could make this external-user-readable-and-writable config file takes higher precedence; so any extensions enabled/ disabled here would overwrite whats in .code-profile.

---

My reasoning: The .code-profile is to intrusive for my need, it can be shared but, IMO, it's not meant to be forcefully applied to others. I don't really care (at least for now) what keyboard bindings, UI layout, or other user specific settings my team uses in their VS Code, but I do want/ need them to enable/ disable specific extensions when working with a specific shared project.

[sandros94]

I would like to double @IronGeek's two cents.

To change perspective: It's like using the .vscode/extensions.json as a package.json from a NodeJS boilerplate. Where I know that I need the listed packages (extensions) to make the boilerplate work, but I can always add my owns (.code-profile) to customize it. The only difference is that we could forcefully disable them to prevent conflicts with others.

---

(As showed by @Cyclodex) A good example is the Volar Takeover Mode. Where, since I'll add the Volar as a suggested extensions inside the .vscode/extensions.json for a Vue3/Nuxt3 repo, I also would like to make sure that it doesn't conflict with vscode's builtin Typescript extension.

This way I know that I'm providing a good starting point for everyone that wants to pull my boilerplate and customize it.

[TonyGravagno]

EDIT: 170916 is complete/closed and will be released in April. See my verification steps. @Cyclodex should be able to adapt his extension to the new data in the .code-profile. Though, after seeing the update, we will have two new questions: "is that extension necessary anymore?" and "do we or do we not have a solution to 'Enable/disable extensions from config file'?" With the extension, and other code that parses the .code-profile, I do believe we will have the tools that we need to do what we have all wanted with this, and anything else should probably be in a new ticket that builds on the (as of April) current platform.

---

Valid comments guys... my only thought so far : At this point in time, five and one-half years after creation of this ticket, we have a solution in #170916 that has already been coded and is ready to fly to the next stage. If we push for more, and there will aways be a wanting for "more", the few lines of change that give us a great solution now won't be used, pending some other grand solution that may never come.

Personally I'm much more inclined to accept what we can get now and then debate whatever "more" might be desired, than to continue to have nothing when we've been feeling this particular pain for so long.

I could be wrong but I believe the 170916 change does address the Volar scenario. For a more complete picture of what case-scenarios might be addressed, see details in the 170916 thread. (And apologies in advance for subjecting anyone to my long notes there, here, or anywhere. 🤣 )

[sandros94]

I don't want to sound like the devil's advocate, and more importantly I've joined this discussion barely 50h ago.

In short, #170916 does provide a workaround for the Volar scenario. But regarding this very issue (#40239) and the message from OP:

This would be a config file, like the extensions recommendations, but with a series of parameters that would allow to enable and disable certain extensions. This would be like a config file for the "[Dis]Allow (Workspace)" setting.

And for me personally goes right within the lines of what you, @TonyGravagno, said:

Personally I'm much more inclined to accept what we can get now and then debate whatever "more" might be desired, than to continue to have nothing when we've been feeling this particular pain for so long.

So to my understanding it was easier to implement such feature in the already-available extensions.json instead of writing a new file .code-profile and the related import/export functions.

Not to mention the potential user error that this could lead:

1. Company "A" acquire a new junior developer and provides the repo for him to work on.
2. Since there could be breaking features with some extensions (maybe already documented on their side) they use the .code-profile workaround to try and prevent any problems.
3. The junior developer wrongly updates the .code-profile and pushes it.
4. Everyone in company "A" wonders why they now have FakeDonald's theme.

[TonyGravagno]

So to my understanding it was easier to implement such feature in the already-available extensions.json instead of writing a new file .code-profile and the related import/export functions.

@Sandros94 - I think you have the idea right and this does not change your perspective, but the code change is in .code-profile, not extensions.json.

And sure, a cascade of errors can result in all kinds of issues, as with any similar introductions of random assets into an ecosystem.

[lx-0]

This is why you should have code reviews before merge. 

Not to mention the potential user error that this could lead:

1. Company "A" acquire a new junior developer and provides the repo for him to work on.
2. Since there could be breaking features with some extensions (maybe already documented on their side) they use the `.code-profile` workaround to try and prevent any problems.
3. The junior developer wrongly updates the `.code-profile` and pushes it.
4. Everyone in company "A" wonders why they now have FakeDonald's theme.

[sandros94]

@TonyGravagno

@Sandros94 - I think you have the idea right and this does not change your perspective, but the code change is in .code-profile, not extensions.json.

Yes I've noticed that the code change was about .code-profile and not extensions.json, that is why I'm curious to understand why that is the case. Because for the first one, IMHO, it resolves only #170916, this issue (#40239) was about adding such feature to extensions.json.

The reason why I'm underlining the fact that it doesn't resolve this issue is because any file that could possibly include user customization is to avoid in multi-dev environments. As per the example I've provided.

Currently all the projects I've worked with have in their .gitignores the .code-profiles and .code-workspaces excluded from getting pushed, for that exact reason.

@sandy081 did an amazing job and was, imo, right in this comment:

[...] But I am little skeptical to announce that this is the solution for https://github.com/microsoft/vscode/issues/40239 and instead I would love if community jumps in and try around and see if it satisfies their needs. [...]

Again, I'll be happy to test that (even as a workaround) when it gets released in april. One thing that probably I'm understanding only now is that in the .code-profile code, there was already a feature to list the extension but it didn't declare if they where enabled or disabled, right? If this is the case I can see why it was easier to solve that issue instead of this one.

[TonyGravagno]

because any file that could possibly include user customization is to avoid in multi-dev environments.

Could you rephrase that with an Edit?

Because for the first one, IMHO, it resolves only https://github.com/microsoft/vscode/issues/170916, this issue (https://github.com/microsoft/vscode/issues/40239) was about adding such feature to extensions.json.

That's not entirely correct. This issue is titled "Enable/disable extensions from config file". The OP was not specific about exactly which file was desired to contained the functionality. The extensions file was soon proposed. But part of this functionality is already in profiles, so that opened a new possible vector. The specifics of the implementation aren't relevant to the desired functionality. Pressing for exactly where functionality is placed would bind developers into a box that easily precludes any solution at all (and here we are), so the discussion here has always been fairly open ... speaking for myself, I've never cared where the functionality was placed, as long as I can tweak Boolean's in some config file.

Currently all the projects I've worked with have in their .gitignores the .code-profiles and .code-workspaces excluded from getting pushed

I agree. A user profile doesn't belong in the code base. Profiles that establish the working environment probably belong in their own separate repo, as in "this is how we work with this project with this specific tooling" with branches for specific environment configurations. (Oh our world has become so complex.) This fits with the exchanges in 170916 where two developers need to collaborate to effectively reproduce a scenario. Dev1 can create a branch of the environment repo that includes a specific profile, Dev2 can load specifically from that branch, and they might discover that something has changed in the extension detail that leads to a manifestation of an anomaly.

Note specifically that 170916 exists because the first production implementation of Profiles did not, until now (I hope), include the extension enablement detail that makes any of that possible.

Related digression: This concept of environment configuration in centralized version control of course isn't new. The problem is that we have so many forms of environment configuration that affect how we approach projects, and all of this data is maintained in different places. For example, we need to establish team coding style conventions for standardized formatting, function signatures, variable declarations, etc. That's not in the code, it's in metadata that needs to be maintained somewhere. VSCode now has extensions.json, code-profile, code-workspace, settings.json, and other files - and each of these contain multiple kinds of settings that we may or may not want to share/mandate in a team. That is a different problem to be solved. For now, these tickets are about just getting the data we need, not about where that data needs to go, which we can discuss (energetically) elsewhere.

One thing that probably I'm understanding only now is that in the .code-profile code, there was already a feature to list the extension but it didn't declare if they where enabled or disabled, right?

Absolutely correct, and that is exactly what 170916 intends to solve.

If this is the case I can see why it was easier to solve that issue instead of this one.

Well, dove-tailing these again, solving that ticket's problem also solves this ticket's problem for a multitude of scenarios. It remains to be seen if it addresses all challenges related to this ticket. My proposal would be to get a determination from our colleagues here about if there is some case scenario that is not yet facilitated by this change, and if so, maybe close the current request and open a new one to address specifics that aren't addressed in the April/current release.

HTH

[TonyGravagno]

The current VSCode v1.77.1 includes the disabled flag for installed extensions in an exported Profile. The mechanism to "enable/disable extensions from config file" is now functional. We can manipulate this file in the UI, with code, or by hand. The software now behaves as described in the original description, and therefore I believe we can close this ticket.

To verify: I exported a profile which contained this random extension detail:

{\"identifier\":{\"id\":\"mxsdev.typescript-explorer\",
\"uuid\":\"ae6725df-337b-473d-8033-1b5951364908\"},
\"displayName\":\"TypeScript Explorer\"},

I then disabled the extension and did another export to another file. This is what the detail looks like:

{\"identifier\":{\"id\":\"mxsdev.typescript-explorer\",
\"uuid\":\"ae6725df-337b-473d-8033-1b5951364908\"},
\"displayName\":\"TypeScript Explorer\",\"disabled\":true},

Note, the detail is exactly the same except for the new "disabled:true" flag. Import the first profile and the extension is re-enabled because it does not include the "disabled" flag - and now after the recent change, because the profile says the extension is not disabled, the installed extension that is disabled gets reinstalled or updated, and then re-enabled.

Open File>Preferences>Profiles, and Show Contents or Export. The list of current extensions displays. Select the text of an extension and you see the marketplace data. If you enabled/disable here, the extension is actually enabled/disabled as normal.

Uncheck an extension and Export the profile. The extension has been removed from the profile. Import the profile. The extension is removed from the current installation because it is not in the profile. That is, the intent of importing a profile is to make the current environment look like that which was exported. So extensions not in the profile are removed, regardless of their enabled status.

Summary: I believe the current functionality responds to everything that we have discussed, and I propose we close this ticket. If a change to the functionality is desired, I propose someone open a new ticket to discuss a Change request.

EDIT: If anyone experiments with this, there is an error, #179648 but it does not interfere with the new functionality, and can be ignored.

[sandros94]

I took sometimes to test v1.77.1 and I can confirm it's a great, easy, workaround. But it is still only a workaround.

My fear for a potential point of failure still applies.

I cannot imagine any medium-to-big dev company using such workaround when the DX failure is one checkbox away:

Not to mention the potential user error that this could lead:

1. Company "A" acquire a new junior developer and provides the repo for him to work on.
2. Since there could be breaking features with some extensions (maybe already documented on their side) they use the .code-profile workaround to try and prevent any problems.
3. The junior developer wrongly updates the .code-profile and pushes it.
4. Everyone in company "A" wonders why they now have FakeDonald's theme.

At this point I'll much more prefer to update the SOP and/or Docs, that the company probably have already provided for that particular project.

More thoughts about point of failures.

Not only that (correct if I'm wrong, because I'm realizing that I know little about VSCode profiles) but:

1. You cannot load automatically a profile once you pull a repo (like the suggested extension popup).
2. That profile gets saved within VSCode and potentially bleed in other repos/projects.
3. There is no way back after the profile has been imported and the user didn't backup his/her/its default profile before clicking overwrite.
4. I cannot wait to have 420 profiles and forget which one was the one for each of the 69 projects I'm working on. Only to find myself at: "F it, I'll reimport it." because I'm wasting precious time.

Closing considerations:

I still think, that this new feature that came with v1.77.1, applies to what was discussed in #170916, but still doesn't fully closes this one. If a workaround was a potential solution this issue wouldn't have been open for more than 5 years. And I still agree and support OP's reasoning (a *.json file, inside a pushed folder like .vscode, that only contains essential configs):

[...] This would be a config file, like the extensions recommendations, but with a series of parameters that would allow to enable and disable certain extensions. [...]

On the flip side: I've got to admit that for a solo/small dev team, having a dedicated profile could be beneficial. I need to dig into this possibility in different use cases.

[TonyGravagno]

Sandros94 - Your scenarios explicitly rely on someone making a mistake, not on an issue with the functionality. We are all screwed when we make specific mistakes. The new functionality does not lead anyone to a new problem.

The problems you describe can manifest with the import of any .code-profile, completely unrelated to this one ticket that focuses on extensions. If you have an issue with the engineering of the file (as some of us do), find or create a ticket for that - your concerns are not specific to the functionality in this ticket.

The solution to the "problem" of what happens if we push and pull a config file is exactly the same as with all other config files: Don't do that. Save this config with all others. What about the problem of people importing the wrong profile? Don't do that, same as with workspaces, tsconfig, user profiles, remote server configs, .env files, and all others. What happens if you import a profile without exporting a preferred default? Don't do that. If you're going to use profiles, a relatively new feature that exists specifically to reconfigure the environment, then get a backup of your environment (a profile) before you start messing with it .... just like with any tool that modifies the environment.

But again, none of that is related to this specific ticket.

RE: "workaround" : We now have a .code-profile JSON config file that includes all of the data we need (for this ticket) about extensions. This config file can be created, manipulated, exported, and imported from VSCode - exactly like all other JSON config files. If we wish to manipulate this with code, we can do so. Where's the "workaround"?

This ticket does not request the re-engineering of the config file (which some of us would appreciate). That re-engineering would be a separate ticket. This ticket asks for the ability to enable/disable extensions from a config file. v1.77 now supports that functionality.

[TonyGravagno]

There are "confused" 😕 reactions to my notes above.

I'm just another guy in this ecosystem, not affiliated with Microsoft. I came to this ticket like many others, while searching for a solution to a problem. To me it seems this ticket has been completed. Any of us can now manipulate extensions via a config file.

What's the confusion? Let's talk it out ... and fergoshsakes, then let's close this ticket and start a new one if it's required.

[IronGeek]

I'll start...

Why .code-profile is not the answer:

• [x] .code-profile needs to be imported and exported, it doesn't automatically applied
• [x] .code-profile can, but is not meant to be manually read/ edited by a human
• [x] .code-profile is personal-ish, it's not meant to be shared as a team configuration

For the last point, I'm quoting sandy081 way back from Jun 11, 2018:

... Extensions recommendation file is meant to be shared (in team). Disabling and enabling extensions is user specific. Merging these two is not a good idea I guess.

While I disagree that extensions enablement is user specific — some extensions are actually used in team scenario (e.g. prettier, eslint, etc) — I agree that the config file for extensions enablement (envisoned by OP) is supposed to be shareable and enforceable (in team).

IMO, this config file doesn't really add much value in non-team scenario.

[TonyGravagno]

Sincere thanks for playing, @IronGeek !

.code-profile needs to be imported and exported, it doesn't automatically applied

Correct. But I can't think of a scenario where we'd want to automatically change our set of extensions. In what environment might one of us want to edit a config file to disable or remove an extension? A manual process must (he says gently) be used to reconfigure like this. Importing a profile is a simple hotkey away - this is not a hassle. What use case am I missing?

.code-profile can, but is not meant to be manually read/ edited by a human

Correct. Many of us don't like the format of .code-profile. But there is a difference between not getting something at all, and not getting it the way we want it. The functionality we've been waiting for over the last 5+ years is now in the software. 🥳 No, the file is still not meant for human consumption, but I maintain that's a different request that is related to all settings in the file, not just extensions.

.code-profile is personal-ish, it's not meant to be shared as a team configuration

Correct. However, most folks here might not be aware of this: As implemented so far, the one file provides many kinds of profile data. Some types of data may or may not be suitable for team or individual use, and some may or may not be suitable for handling through a repo (to address another good point earlier). When creating a profile, just export the desired functionality for the specific use case. When imported, only the settings in that one file change. That is, to be clear, we do not Need to share personal-ish settings with a team - doing so would be an error.

What I'm suggesting is that Profiles are still fairly new, and the possibilities that we have for using this feature might be more expansive than, and might not directly correspond to, the way we've been thinking about using them - whether that was intended or not by the designers.

While I disagree that extensions enablement is user specific — some extensions are actually used in team scenario (e.g. prettier, eslint, etc) — I agree that the config file for extensions enablement (envisoned by OP) is supposed to be shareable and enforceable (in team).

Agreed. In a team or as individuals, we can implement policy to name files according to their purpose:

ProductX_Extensions_v1.code-profile
Extensions_For_React_TypeScript.code-profile
Extensions_For_Java.code-profile
Company_Keybindings_v2.code-profile
WordPress_PHP_Snippets.code-profile
Drupal_PHP_Snippets.code-profile
Tony_UserSettings.code-profile

IMO, this config file doesn't really add much value in non-team scenario.

I disagree. As an individual rarely working within a team I can use all of the above profiles, and I suspect that now given these examples you probably can see this as well.

In a team, individuals should not be modifying team-oriented profiles to their own whims. Team-oriented profiles should be managed by a designated manager, and centrally located. Personal settings should never be exported into a profile that is destined for team consumption.

This paradigm is not new or unusual. We have centralized email filters, and client-side. We have centralized email templates, and personal. We have centralized contact lists and calendars, and client-side counterparts. What IS unusual for many of us is doing this kind of collaboration with our IDE, and it's something that we're all trying to get a grip on with this specific tool.

OK, so I've responded to every one of your points of confusion, and we are in agreement with all but the last. I still maintain that we have what we asked for, a config file that can be maintained in the UI or programmatically. Other changes belongs in separate tickets, and this ticket should be closed as complete.

I welcome more requests for clarification, rebuttals, and hopefully some agreement.

I'm aware that I probably outstayed my welcome on this topic a long time ago, and a "please STFU" might be in order, though not good decorum here. I think this ticket needs some management and I'm doing my FOSS part to handle that. Thanks for bearing with me.

[IronGeek]

Correct. But I can't think of a scenario where we'd want to automatically change our set of extensions. In what environment might one of us want to edit a config file to disable or remove an extension? A manual process must (he says gently) be used to reconfigure like this. Importing a profile is a simple hotkey away - this is not a hassle. What use case am I missing?

For me, the original need for this config file is to have my team use the same set of extensions (disabled/ enabled) when working on certain project on vscode. Think of it as .editorconfig, or .eslintrc.js or tsconfig.json but for extension enablement. I can easily publish this config file to a repo alongside the project source, which when opened by VS code, will automatically enforce the said extension enablement.

Yes, this would only work for VS Code that's why i prefer it tobe in the .vscode folder. And Yes, this is a team-oriented scenario, like a said before:

IMO, this config file doesn't really add much value in non-team scenario.

---

I disagree. As an individual rarely working within a team I can use all of the above profiles, and I suspect that now given these examples you probably can see this as well.

I'm refering to the original config idea here, not .code-profile. The .code-profile certainly works for personal configuration, I have no issue on that, rather my issue is using it for team related configuration.

I still maintain that we have what we asked for, a config file that can be maintained in the UI or programmatically. Other changes belongs in separate tickets, and this ticket should be closed as complete.

This ticket has been open for more than 5 years since 2017, The original solution proposed is to extend the .vsxode/extensions.json. The config file use-case for team related scenario has already been discussed since the beginning. Given that, no, I don't think this ticket is complete.

I'm sorry for saying this, I know the team needs to prioritize which feature gets implemented, but if we close this one, and open a new ticket for the unmet changes? Do we wait for yet another 5 years? At least keeping this ticket open will add some weight/ pressure, given how long it has been kept open.

[parched]

I work in a company where most of the people doing development are just dabbling with Python and are not experienced developers. I have a hard enough time getting them set up with Git and GitHub, but I hope that when they clone the project, the VS Code settings in the repo can have them ready to go. Unfortunately, it doesn't work. I have the extensions they need set in extensions.json but, they have conflicting extension also installed (used for other projects). They are getting errors like "line to long". They try to fix it, then save the file, but it reverts back because the formatting extension we're using for this project uses a different line length. At this stage, they come to me and ask what's wrong. I have to tell them

(sigh), that error is from an extension we're not using for this project, you'll have to disable for this workspace

How do I do that?

You have to click on that thing that looks like blocks, search for flake8, click on the cog, then click disable workspace

Couldn't find it, call?

(call ensues)

Now, what was I doing before being interrupted?

---

I tried the new .code-profile with just the project extensions in it, but when I imported it, it disabled all the project-agnostic extensions I use. Also, the manual import step is something I'd like to avoid for the other developers.

[sandros94]

(sigh), that error is from an extension we're not using for this project, you'll have to disable for this workspace

How do I do that?

You have to click on that thing that looks like blocks, search for flake8, click on the cog, then click disable workspace

Couldn't find it, call?

reading this gave me PTSD flashbacks...

[TonyGravagno]

Friends, try this (numbering consistent for reference)

Create a profile that represents your current personal environment:

1. menu > File > Preferences > Profiles > Create > from Current
2. Give it some meaningful name. I'll suggest "Production".

Verify that you are running the defined Profle:

3. menu > File > Preferences > Profiles ... you see that you are now using Production.

Save this for yourself as a backup:

4. menu > File > Preferences > Profiles > Export
5. With all tree nodes selected, click Export, select Local file.
6. Save as something like Production_230420.code-profile, corresponding to its name/purpose.

At any time, you can come back to this for all settings, snippets, extensions, even your UI state. Everyone in a team should do the above.

We're going to create a new profile for a project. I'll use React/TS for this example, choose your own specifics. I work with Java, PHP, JS/TS, C#, shell scripts, Apache configs and many others for which I have extensions, but for a React project I don't care about anything non-related.

Create a new profile based on your current personal environment that will be used for React/TS:

7. menu > File > Preferences > Profiles > Create > from Current
8. Give it some meaningful name suitable for team usage. I'll suggest "Team React TS".
9. menu > File > Preferences > Profiles (you see you are using this new profile) > Export
10. Uncheck all top tier nodes except Extensions. You do not want to share settings, but you might want to share keybindings, React-related snippets, or whatever else might be available here based on your extensions.
11. Uncheck extensions not related to React or TypeScript (in this example). If you're not sure about an extension, click the name to open the Market page.
12. Click Export > Local file.
13. Give the file a name. Unless you're pushing to a repo, timestamp it as ReactTS_230420.code-profile.

You've created a profile that is suitable for a team, a specific project, and a collaboration repo. It does not have personal settings. Your current "Team React TS" profile is not the same as the one you exported. You are running a profile named "Team React TS" but it was created from your full set of extensions.

14. To actually set your profle to "Team React TS", you need to Import the file you just exported and OK the prompt to over-write.

Your set of installed extensions actually changes down to the defined subset for React.

15. Toggle your profle back to "Production"

All of your extensions come back. Prior to 1.77, disabled extensions wouldn't come back! The Disabled flag was not stored in .code-profile.

At step 11 we uncheck extensions to be exported. On import, installed extensions are actually uninistalled. That may not be desirable for team members who work on other projects (who can still recover their production environment simply by changing profiles). As noted above, with v1.77+ we can now export the disabled status of an extension.

If a team member has project-related extensions that they don't want to be removed for a project, we now have the ability to simply disable them. The team member can re-enable these extensions while using the profile. (More about this below.) If you do not want this versatility, where an extension might introduce anomalies, then uncheck extensions rather than exporting them in the disabled state.

Summary so far: To use any profile, personal or project-specific:

16. menu > File > Preferences > Profiles > select TheName

Want to avoid the menu? Setup a keyboard shortcut for workbench.profiles.actions.switchProfile, or (not sure) set a shortcut/hotkey to any specific workbench.profiles.actions.profileEntry.#####.

---

@IronGeek The above works exactly as you have described here:

For me, the original need for this config file is to have my team use the same set of extensions (disabled/ enabled) when working on certain project on vscode. Think of it as .editorconfig, or .eslintrc.js or tsconfig.json but for extension enablement. I can easily publish this config file to a repo alongside the project source, which when opened by VS code, will automatically enforce the said extension enablement. Yes, this would only work for VS Code that's why i prefer it tobe in the .vscode folder.

And specifically to your point here:

The .code-profile certainly works for personal configuration, I have no issue on that, rather my issue is using it for team related configuration.

I have described exactly how this does work for team related configuration. We can also export a profile to a Gist, further proof that this mechanism supports team collaboration. (Side note, I'm not comfortable with all of the permissions required to export to Gist, but that's a completely separate issue.)

I think the problem we've all had here is that it's never been entirely clear how Profiles can actually be used. The problem is that Profiles didn't do what we wanted so we thought Profiles were not the answer. But with the fix in 1.77, Profiles now live up to their original definition in this respect, and (to my surprise too) the Profile really is the solution to a primary use case for this ticket.

Stated another way: we went looking to other files because we didn't know Profiles could do this with a fix. Now with the fix, we can see that Profiles do provide an adequate solution - we don't need to maintain the pursuit of implementation of this functionality in other files.

---

There are a couple things that remain hanging:

1) The extensions property of the .code-profile JSON object is still ugly/stringified. (For anyone joining this late, this is only a detail for those who want to use code to manipulate extensions in the config file with code.)

 "name": "React TS",
  "extensions": "[{\"identifier\":{\"id\":\"afzalsayed96.reacticons\",\"uuid\":
\"ba9458d6-6cb3-48d3-9a4e-38d37187cdd6\"},\"displayName\":\"React Icons\"},
{\"identifier\":{\"id\":\"alduncanson.react-hooks-snippets\",\"uuid\":
\"d4421060-16f8-46df-a0f3-bf6d53592386\"},\"displayName\":\"React Hooks Snippets\"},
{\"identifier\":{\"id\":\"alefragnani.bookmarks\",\"uuid\":
\"b689fcc8-d494-4dbf-a228-2c694a578afc\"},\"displayName\":\"Bookmarks\"},

Whoopdee doo. We're programmers. We can handle it. The purpose of this ticket was to get the detail we wanted (extensions) into a config file. As of 1.77 that has been fully implemented.

I know the team needs to prioritize which feature gets implemented, but if we close this one, and open a new ticket for the unmet changes? Do we wait for yet another 5 years?

Yes, if we leave this ticket open to re-engineer .code-profile, it will be another 5 years. #148829 already exists. It was closed. Petition by re-opening that ticket or with a new ticket. But I would not upvote any priority for that one.

2) @parched brings up a valid use case for sharing a profile in a team, and a desire for less pain:

I tried the new .code-profile with just the project extensions in it, but when I imported it, it disabled all the project-agnostic extensions I use. Also, the manual import step is something I'd like to avoid for the other developers.

Yes, on Import our current profile is reset such that any non-profile extensions are uninstalled. I don't think we can Import with an option to augment/merge the current environment. [ @sandy081 ? ] That could be considered a part of this ticket, where we want to "enable/disable extensions from config file" but not exclusively from that config file.

I think that's completely valid for this example environment : I have a set of extensions that I use to do my job. I load a team profile that doesn't include my preferred extensions and my extensions get uninstalled. I need to request to the team manager for one of us to install the desired plugin but disable it for the team, and save into an update of the profile. That way everyone gets it but it's disabled for everyone else, and I need to enable it rather than installing it when I switch to the profile. In a team with more than a few people who want to use their own tools, that's a hassle of a new category.

However, after we import a profile, we can install and enable other extensions that then become a part of our local installation of that profile. If the profile is updated elsewhere, we aren't affected unless we re-import the .code-profile as a new version of the truth. That is, you can import the profile once, which sets it as your current profile, you can install your preferred extension, and from then-forward you can continue to switch between that profile and others without losing your preferred extension. You only need to reinstall or re-enable when you re-import the same team profile.

I can easily see a request for extension merging as being a separate ticket. It requires a UI option to ask "Do you want to merge, or replace your extensions?" It would raise arguments from managers who don't want to give their team such an option - perhaps a flag in the profile. It would raise requests for merge/replacement of other settings. It would raise concerns about how to merge settings in extension-created profile detail. It would drive some extension developers to support profile-merge functionality in addition to profile replacement. I really don't think this one ticket should support this whole new use case under a single wrapper.

About "the manual import step is something I'd like to avoid for the other developers": See https://code.visualstudio.com/docs/editor/profiles#_workspace-associations which includes this:

When you select create or select an existing profile, it is associated with the current workspace and whenever you open that folder, the workspace's profile is active. If you open another folder, the profile switches to that folder's associated profile if one has been set or remains on the last used profile.

I have not looked into how that works, but it seems the functionality you describe is already in VSCode. If there is confusion about how to implement it, ask a question somewhere, or create a ticket for a documentation enhancement, or create a ticket for a change to that specific feature.

---

We come back to : full agreement (with those who have participated here) about what use cases "should be" supported, verification that these use cases ARE supported, and my open request for a reason why this ticket should remain open.

Again, we don't always get what we want exactly as we imagined it. Our vision of implementation doesn't always match the final product. But I maintain that we have the functionality we've been asking for and anything else should be presented in a new ticket.

If that's not correct, please submit a use case that is not covered that truly fits within the scope of this ticket. Please don't bully this ticket into supporting every nuance, or yes, it will remain open for another five years or until the bot closes it. Personally I don't care because I think the job is done and that's all I care about. If you want to argue here that you still can't do things, go ahead. But, and this is my ongoing concern, I think pursuing nuances in this ticket won't be productive. We're lucky and appreciative that @sandy081 took the initiative to process #170916 - he could do so because it was a focused into a separate ticket. Every new idea deserves a separate debate in its own ticket. We don't have the ability now to upvote other good ideas or valid concerns here because of the clutter in this ticket. There's nothing "actionable" here anymore.

Thanks.

[IronGeek]

However, after we import a profile, we can install and enable other extensions that then become a part of our local installation of that profile. If the profile is updated elsewhere, we aren't affected unless we re-import the .code-profile as a new version of the truth. That is, you can import the profile once, which sets it as your current profile, you can install your preferred extension, and from then-forward you can continue to switch between that profile and others without losing your preferred extension. You only need to reinstall or re-enable when you re-import the same team profile.

@TonyGravagno I think you're missing my point. The above is exactly why .code-profile does not meet my requirements. I need the config file to enfore extensions enablement, whenever the config is updated I expect the changes to be propagated to whomever is using the same configuration without the needs to re-import it.

[josh-hemphill]

@TonyGravagno Couldn't a lot of the same be said about .code-profile in relation to extension recommendations, should we get rid of the extension recommendations configurations since they can be controlled from .code-profile? The ability of .code-profile to enforce the enablement of extensions is a consequence of it being a solution for managing the whole state of VS code, which just happens to include which extensions are enabled. I think a lot of us wanting to keep this open just do not want to deal with a whole separate system, whose features are far more and more complex than what we need or want, especially when there's an existing config file whose domain of control would nicely encompass the enablement/disablement of extensions. To borrow from Windows ecosystem for an analogy, if feels like saying windows shouldn't have a UI setting for something because it can be controlled from registry keys and group policy.

I can't speak for other's but I don't see my team ever using code profiles, the added complexity is not worth trying to use them for one setting; especially in high turnover environments where I'd be spending my time every day trying to explain code profiles to junior devs.

[TonyGravagno]

I completely agree with the most recent comments. Seriously, the recent change does not directly solve the use cases described. You're looking for extensions to be defined by the workspace, with automatic environment reconfiguration of extensions on project startup. You're right - we still don't have that.

What we do have is close but still not exactly what you want : We can specify a profile name and a workspace name from the VSCode CLI :

• code Test_React.code-workspace --profile "React TS"
• code . --profile "WordPress PHP"
• code D:\dev\ProductX\productx.code-workspace --profile "Z:\VSCode\TeamJava.code-profile"

Example for team usage in Git repo for ProductX :

.gitignore
launchvs.bat
productx.code-workspace
productx.code-profile
docs
gulp
src
README.md
...

launchvs.bat

code .\productx.code-workspace --profile .\productx.code-profile

Instructions to team : "If any company or project repo has a launchvs.bat or launchvs.sh file, click it to start VSCode."

I just did this. It works Great. I have two VSCode windows option for two different projects, and the extensions for each are different because I'm using different profiles to start each window.

"But we need this to happen automatically for team members without telling them to click a BAT/SH file to load.

OK... There's almost a solution for that.
In the file foo.code-workspace, add the following "tasks" property:

  "tasks": {
    "version": "2.0.0",
    "tasks": [
      {
        "label": "Auto-Load Profile",
        "command": "${command:workbench.profiles.actions.profileEntry.-6b7b3fc}",
        "runOptions": {
          "runOn": "folderOpen"
        }
      }
    ]
  }

When the workspace folder is open, on opening the workspace, this task is executed to invoke the command by ID : workbench.profiles.actions.profileEntry. The final part of that command, "-6b7b3fc" in this example, is an internal ID for a locally loaded profile.

That works! However, a problem with that is that the profile must already have been imported. I lack the skill with VSCode Task JSON to make that Import a profile and then set it for the project. I tried these variants :

"command":"${command:workbench.profiles.actions.importProfile}",
"args": ["D:\\My\\Path\\Profiles\\ProductX.code-profile"],
// OR
"command": [
  "${command:workbench.profiles.actions.importProfile}",
  "D:\\Development\\VSCode\\Profiles\\Production 230420.code-profile"
],
// OR
"command": {
  "quoting": "escape",
  "value": [
    "${command:workbench.profiles.actions.importProfile}",
    "D:\\My\\Path\\Profiles\\ProductX.code-profile"
  ]
},
// OR
"command": "${command:workbench.profiles.actions.importProfile}\nD:\\My\\Path\\Profiles\\ProductX.code-profile\n",

None of the above functionality worked prior to v1.77 because extension Enabled status wasn't saved in a portable manner. Now it is. If we can script a Task to Import and then set a .code-profile, then the recent use cases Are handled as described by @IronGeek and @josh-hemphill .

Yeah, I think this is a hack too, but again, my goal is to be able to use the functionality that exists until something better comes along. Part of the problem here is that the scope of the challenge for this ticket was not limited, so no matter what we come up with here the line is always going to move just beyond that to accommodate another use case. That's not a criticism, it's just the way this has unfolded.

HTH

[AaronBeaudoin]

Inspired by a real-world scenario at my job:

Bob: "Hey Aaron, I'd like to get up and running with our internal company development project." Me: "Hey Bob, sure thing! Just clone our internal GitHub repo, and open the directory in VS Code."

Half an hour later...

Bob: "Hey Aaron, I've opened the project in VS Code, but a bunch of stuff isn't working." Aaron: "Yeah, that's because you need to disable a few extensions which conflict with the extensions we are using." Bob: "Bro, wouldn't it have been better to set up VS Code to automatically set that up when I open the project?" Aaron: "Hey Bob, yeah, it definitely would have. Unfortunately, VS Code has had an open issue asking for support for that feature for 5+ years. Not sure when, if ever, it will see the light of day. Check back in 2025."

I wish I didn't have to tell people that. Maybe I'm missing something, but the assumption that I would want to always enable all of my extensions all the time for all of my projects seems hilarious. I can't imagine any project where I wouldn't want to have the option to setup a default extensions set which the user can override—but only if they even care enough to think about it. It's the same reason I love sandboxing my projects in development with Docker Compose with sane defaults while grabbing user-specific configuration from a .env file ignored by version control. It's the same reason why I have only a few global Git options and the rest of my settings are in my local .git/config. I generally want my projects to have a default setup that works out of the box and enables/disables the specific thing pertaining to that project—while still giving me the option to add my own customizations as an additional layer on top that. If I copy/paste the repository onto another computer then I'd like to not have to reconfigure the environment again apart from my own personal customizations.

It's a pretty simple idea that goes way beyond personalizing VS Code extensions. I want Bob to open the project directory in VS Code and just have it work. No creating a "workspace". No messing with "profiles" or whatever. Just the directory he cloned from GitHub, and the joy of working with an IDE that was already setup to do what he needed.

[PwrSrg]

THIS. ☝️☝️☝️

[TonyGravagno]

Load the extension called "Magic". It knows what you want to happen and just does it correctly in all possible environments with zero configuration.

Sorry for being snarky but c'mon guys, are we technicians or not? In my last note above I described exactly how to do exactly what you want in just a few minutes. Someone needs to define the parameters that make that happen in exactly the way you want it to happen.

I had forgotten about this thread because everything is working now. What's the deal? Since when are we adverse to a little configuration in this nerd-o-world of ours? Does someone need to write documentation? I already did it above - Hey Microsoft, or any company with interest, get someone to clean up the doc I wrote, or pay me to write docs or make videos with and for you. I'd love to.

To be clear - Yeah, this whole thing about workspaces and profiles has rolled out into somewhat of a mess. But we're not going to get anyone to re-engineer it for us. We need to roll with the FOSS or use something else. I can't afford to stand on indignation that FOSS is "quirkily engineered"^:tm: or difficult to configure. I'm not getting paid to have conversations with Bob. I need to use this stuff as-is. No, it's not perfect in this area but it's damned good, completely functional with regard to this thread, and I haven't seen a use case yet where it doesn't work with the current release.

I do see a lot of people resistent to using it as-is, as dirt simple as it is. We should take this discussion to Gitter or Slack. What IS the precise issue you folks are having with using this simple feature as-is? Stop playing end-user with vague downvotes and be specific about what is not working for you given the information provided since the related change that should have closed this thread.

[josh-hemphill]

If you want something specific, I can't use your solution because VSCode task runners fail in my corporate VMs environment because of permissions/ownership issues. Could that be resolved with future unrelated fixes? Sure, but none of this is suitable for the use case of trying to manage things for devs that won't use the terminal or click extra buttons or whathaveyou.

I may be able to do all that easily, but do you know what else I can do? Click the few buttons to disable the extensions I need to... The WHOLE POINT is that disabling the extensions is supposed to make it so we don't have to give special instructions to "devs" or anyone loading a project.

Don't even consider the people we're trying to manage environments for as a "dev" for these purposes, they're going to be messaging me (multiply by the number of people trying to load a project on any given day) asking me to repeat to them how to load the project and if there isn't a better way. THEN I'm going to have to listen to them pine about how "I've never had to do things like this when I use Visual Studio, can't I just load it in Visual Studio?"

[Hai-San]

As we've seen, this won't be resolved and if it is, it won't be anytime soon. Because of something cultural, many developers have the habit of finding it cool to do more complex things, unfortunately I don't like that, I like practical and simple things.

I have WSL with ubuntu 20.04.

I solved this problem as follows:

Create a folder with the name of the project technology:

Let's call it vue

Inside the vue folder create 2 folders:

data and extensions

Now in the .bash_aliases file create the following command:

alias vs-vue='code --extensions-dir "C:\your-path\vue\extensions" --user-data-dir "C:\your-path\vue\data"'

Whenever you run the vs-vue command it will open a unique vscode where everything you install and configure will only be in it. So you can create several folders with your specific aliases and have everything separate for each project.

[TonyGravagno]

@Hai-San I'm curious why it is not acceptable to add --profile to your alias. The challenge for this ticket is to select extensions with a config file. The .code-profile file is exactly that. So why do you still feel the need to have an extensions folder?

The extensions folder is a valid solution (but icky) to the challenge of configuring extensions. But that's not related to this ticket. If the .code-profile file is not a valid solution, what specifically is wrong with that solution that precludes you from using it?

Will anyone just say "I don't understand what the blasted .code-profile is or how to use it" so that we can maybe shift this into a new request for documentation? That's a different challenge than "I know this ticket is about disabling extensions from a config file, and I know .code-profile does allow this, but this specific file is not acceptable because ...".

Remember, I'm not a Microsoft guy and not a maintainer of this project. I'm just another dev who was interested in this ticket and I'm really confused about why it can't be closed given that a working solution was provided.

If there is a different use case for which the existing functionality doesn't apply, personally I'd suggest new tickets for specific use cases to enhance what we have. The inability of a solution to address all use cases doesn't mean there isn't a solution, it means someone wants something else in addition to this solution. In everything we devs do, that means another ticket.

[AaronBeaudoin]

@TonyGravagno Perhaps I can break down why in my opinion this ticket can't be closed. The title is currently "Enable/disable extensions from config file". Now, I just tried exporting a .code-profile from VS Code to see what it looks like, and I'd stay it's obvious that it was not mean't to be edited manually. Consider that, for example, Docker Compose is configured via a config file called compose.yaml. Here is what a compose.yaml file might look like:

version: '3.7'
services:
  wireguard:
    image: linuxserver/wireguard
    container_name: wireguard
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=${TIMEZONE}
      - SERVERURL=${VPN_SERVER_URL} #optional
      - SERVERPORT=51820 #optional
      - PEERS=1 #optional
      - PEERDNS=auto #optional
      - INTERNAL_SUBNET=10.13.13.0 #optional
      - ALLOWEDIPS=0.0.0.0/0 #optional
    volumes:
      - /usr/share/appdata/wireguard/config:/config
      - /usr/src:/usr/src # location of kernel headers
      - /lib/modules:/lib/modules
    ports:
      - 51820:51820/udp
    sysctls:
      - net.ipv4.conf.all.src_valid_mark=1
    restart: unless-stopped

Even if this was a regular .json file, it's clear it was designed to be edited. But suppose it looked like this:

{"version":"3.7","services":{"wireguard":{"image":"linuxserver/wireguard","container_name":"wireguard","cap_add":["NET_ADMIN","SYS_MODULE"],
"environment":["PUID=1000","PGID=1000","TZ=${TIMEZONE}","SERVERURL=${VPN_SERVER_URL}","SERVERPORT=51820","PEERS=1","PEERDNS=auto",
"INTERNAL_SUBNET=10.13.13.0","ALLOWEDIPS=0.0.0.0/0"],"volumes":["/usr/share/appdata/wireguard/config:/config","/usr/src:/usr/src",
"/lib/modules:/lib/modules"],"ports":["51820:51820/udp"],"sysctls":["net.ipv4.conf.all.src_valid_mark=1"],"restart":"unless-stopped"}}}

Hmm, doesn't that look familiar? It's minified .json—just like a .code-profile file! Editing that sure looks like a lot of fun.

Consider this as well: When I run docker compose <sub-command>, do I need to first load up my compose.yaml config/profile? Absolutely not! It happens automatically—because that's how config files are supposed to work! Like, for example, .vscode/settings.json.

Therefore, a solution for the title "Enable/disable extensions from config file" has still not been provided. .code-profile is not a config file designed to be editable—it's more like an export output mean't to be fed back into the same system it came out of. And it isn't read automatically by VS Code and applied for the current directory.

I'm not ripping on .code-profile. I have no doubt it is a fantastic solution—but for an entirely different problem. I would say that this feature request remains wholly unaddressed.

[TonyGravagno]

@josh-hemphill wrote:

I can't use your solution because VSCode task runners fail in my corporate VMs environment because of permissions/ownership issues.

So code WorkspaceName.code-workspace --profile "ProfileName" won't work?

The challenge for this ticket is to "disable extensions from config file". If your users don't have the ability to specify a config file from CLI or within the UI, then what kind of solution were you looking for from this ticket?

I think the thing people are looking for is a way to auto-load a profile with a workspace. That way the workspace carries with it all of the extensions required for a team to operate on it. I don't know where that link is specified but it seems it's in there somewhere. Surfacing that would be a different ticket ... which might already exist.

See this StackOverflow Q&A where the request is "It would be great if a workspace would automatically use a specific profile" and the answer is "it already does that".

Does that help any? If not, what exactly are you looking for in a solution like this? And at what point can this ticket be closed as existing functionality so that new tickets can be opened to request new functionality that builds upon it. Every possible use case can't be bundled into single tickets or every project would have a single ticket "make this project do everything that everyone wants".

As always, I'm not dismissing the valid concerns - I'm trying to keep this light while still pointing out the practical nuances that for some reason are understood everywhere except in this one ticket.

Perhaps a good read through the doc might help to see all of the use cases that ARE possible with Profiles?

https://code.visualstudio.com/docs/editor/profiles

EDIT: Final note, the issue with "VSCode task runners fail in my corporate VMs environment because of permissions/ownership issues" might be a completely different issue that should be taken up separately. See https://github.com/microsoft/vscode/issues/180844

[josh-hemphill]

So code WorkspaceName.code-workspace --profile "ProfileName" won't work?

Only if it contains tasks will it fail, but it's still somewhat problematic.

Perhaps a good read through the doc might help to see all of the use cases that ARE possible with Profiles?

Nowhere under "Use Cases" does it list anything like "applying project configurations". The stated use cases are sharing configurations for Environments not for version-controlled Project configs.

From what I can gather:

• The code-profile does not work for applying or enforcing a config on users, since it is primarily the user's own configuration that is being tracked. It should not be kept in version control because anything user-specific that changes will automatically be included and have to be backed out in version control later, harming version control if you try to.
• If it's not version controlled, maintaining extension configs inside it will be a battle, changing it back and forth with numerous scripts/tasks.
• It is not designed as a "Config Source of Truth", it is designed as a "Try my config profile and see how these User configurations work for you"

The code-profile is not for applying config, it is for saving config, which are markedly different in multi-user environments.

EDIT: Final note

Yes, I tried to mention that; I just included it to highlight that corporate environments don't always have the luxury of being able to hack things into working like that.

The code-profile may eventually have some use for me in testing and comparing different User configs from different users so I can find conflicts and issues in project-level configs, but it will never belong inside a project's version control or be able to be used to apply project-level configurations.

[TonyGravagno]

@AaronBeaudoin - Your completely valid note on the structure of .code-profile has been discussed in this thread and elsewhere. The file has been described as "not intended for human consumption". I and others have commented that this was a silly engineering design flaw. I think we're all in agreement about this condition.

I would say that this feature request remains wholly unaddressed.

Not "wholly", just inconveniently. I'm not playing with words here, just being a technician : We can "enable/disable extensions from a config file", by hand, by code, and in the UI. It's just ugly and not user-friendly. We got a solution. To get a "pretty" solution for a human-modifiable file like .code-workspace and all of the other JSON, we should open a new ticket if it doesn't already exist. (Anyone familiar with HHGTTG thinking "Beware of the leopard" about now?) To avoid breaking code that's written against this file (with a simple JSON Parse against the simple JSON Stringify) a ticket like that should be created and processed soon (I think there is/was one), otherwise we'll get the resolution "can't change this because it will break existing code".

As always, I'm not completely happy with this solution either, but it IS a usable solution for many (most?) use cases, via JSON editor (yuck), code, and UI. Let's not stand on "yeah, but it's not pretty" or most of the FOSS on this planet will be regarded as unacceptable.

[AaronBeaudoin]

I'm not playing with words here, just being a technician : We can "enable/disable extensions from a config file", by hand, by code, and in the UI. It's just ugly and not user-friendly. We got a solution.

Editing the .code-profile isn't going to automatically install or uninstall any extensions until I manually apply it afterwards by specifying a CLI argument or via the UI. Implicit to the idea of the kind of config file people are wanting in this issue is the expectation that it will be used and applied automatically by the consuming application. So no, we don't have a solution.

Let's not stand on "yeah, but it's not pretty" or most of the FOSS on this planet will be regarded as unacceptable.

.code-profile isn't pretty, but that's not the point. The point is that by design it isn't a config file—it's an export output.

[TonyGravagno]

@josh-hemphill Thanks for the exchanges...

So code WorkspaceName.code-workspace --profile "ProfileName" won't work?

Only if it contains tasks will it fail, but it's still somewhat problematic.

The environment is being reconfigured. Software is being uninstalled and reinstalled. That is what this ticket is about - configuration via a config file is just the user-interface for that process. Yeah, I completely agree that the operation that is resulting from the configuration settings is going to cause problems in your installation where the ability to run tasks to perform this operation is limited. But that's a separate challenge entirely, to be detailed and remedied in its own right.

Perhaps a good read through the doc might help to see all of the use cases that ARE possible with Profiles?

Nowhere under "Use Cases" does it list anything like "applying project configurations". The stated use cases are sharing configurations for Environments not for version-controlled Project configs.

A Workspace is a single instance of a class of similar Projects. Look at a Profile as an abstract class that declares the requirements of all similar projects which derive from the base. You can open many Workspaces with the same Profile to make use of the same settings, extensions, keybindings, tasks.json, snippets, and views. From an abstract Profile (like for all ReactJS projects), you can create a concrete Profile for your team to use for JS-only ReactJS, and another for TS-ReactJS. These profiles can be used for one or many projects that require the same consistent environment.

The .code-profile file can be saved in a project repo for use with that specific project. You can create a separate repo with all profiles for all projects, which can be pushed and pulled so that the team can always get the most recent updates to all profiles. How you configure this is up to you.

Your notes about version control imply that individuals are pushing personal preferences into a team repo for common consumption. 1) No one except an admin should be pushing configs to all users. 2) The same problem exists for any configuration file, even .code-workspace - this is no different. If you have a project repo with a .code-profile and you don't want anyone to push into it, there are solutions to this challenge with git or CI. git-allow-prevent-commit-and-push-of-certain-files A question to ask here is, do you really want a non-dynamic file in a dynamic repo? None of this is related to this ticket.

I do see that there is a hassle where a dev loads a profile, makes changes to their local config, and then loses the local config when they pull the same profile back. There's also the requirement to re-check and modify the environment whenever a project is loaded. Well, are we providing a defined config for a specific purpose or not? Do we want to guarantee consistency or not? This is not a new scenario in any way.

The code-profile may eventually have some use for me in testing and comparing different User configs from different users so I can find conflicts and issues in project-level configs, but it will never belong inside a project's version control or be able to be used to apply project-level configurations.

Does the analogy of profiles to abstract classes help with that at all? Yes, you can VC some profiles per-project, some per team, some per-user. There is a lot of versatility that we have yet to recognize with this new functionality.

Side note, I didn't like the idea of profiles being applied to this ticket when I first got into here - see my earliest comments. But when it looked like a simple fix/enhancement to the profile was the solution to this long-open ticket I jumped on it. Only later when I really started playing with it did I really form an appreciation. I hope others might follow a similar trajectory.

[TonyGravagno]

@AaronBeaudoin I understand what you're saying and all of the nuances, but we'll need to agree to disagree. This ticket sat for years and now we have "something" that works. For me, that's good enough. The open/closed state of this ticket isn't relevant. The functionality is in production. That's all that matters. My goal has simply been to help others to understand how it might work for them - and sure to recognize how it is not idea for others.

Do we really want or need a tool that dynamically reconfigures the environment when a config file changes? We can change all of the settings in the environment, and yes, they change dynamically. 🎉 But thinking about this ticket and modifying extensions with a config file, are we really talking about dynamic changes while we are working on a project, as in, some external process is going to modify our extensions while we're working in code? I think not.

For extensions I think the most common use case is that we want to make changes to our extensions, save that setting, and then recall it the next time we work on specific projects. The second most common use case would be for sharing those configurations, where someone loads the config when working on specific projects - the fact that the config is JSON isn't relevant. A third nerdy use case might be for code to operate on the config files. Again though, I can't imagine a scenario where I'd want code to modify a config file that would then dynamically change my environment under my project. I can kinda see a tool that inspects and modifies extension enablement in config files - that's possible now where it was not before.

.code-profile isn't pretty, but that's not the point. The point is that by design it isn't a config file—it's an export output.

OK, so then it's imported and we have a list of profiles from which we can select per-project. Why is that a problem? It doesn't work like everything else? That seems to be the same as "it isn't pretty". Is there any other grounds for this being an unacceptable solution (for now anyway) ? What is the exact technical or workflow scenario in which this solution is inadequate - other than the valid task automation VM issue that @josh-hemphill noted?

[josh-hemphill]

Do we really want or need a tool that dynamically reconfigures the environment when a config file changes?

We're not talking about installing or uninstalling extensions (at least most of us aren't, that's already handled), users have already consented to installing whatever extensions they already have installed; enabling or disabling any subset of them should be fair game. I would much rather have all my extensions disabled by default and enable them in user and project level configs (though there's complexity with built-in extensions, but that can be hanlded)

The extensions.json file already changes the environment, albeit with a prompt.

All configs across all projects in my organization are saved and tracked in VC in their respective projects, because there are so many different organizations sharing our private projects between each other, everyone expects that if they clone a project, everything they need is defined within it; there are no separate repos that have to be maintained and applied to have the proper environments for any given project.

But the set of extensions that are needed or should be enabled, is maintained by the same people maintaining the repo. We currently use the extensions.json extensively and document ones that need to be disabled, all within VC, because it change often, and the changes originate with power-user devs that work on improving builds, configurations, and DX; but they're still devs only assigned to the individual projects, who just need to be able to set some extensions as needing to be disabled.

There is no room in an environment like that to have any concern for the User-level configuration, or who or what else could be effected by applying some code-profile; it is out of scope for what those devs need to be concerning themselves with, but what extensions need to be disabled is within scope, so like the extensions.json they just need to list the extensions to disable separately from anything else at the project level.

[pc-erin]

@TonyGravagno I'm having a really hard time figuring out your opposition to this request.

Let's say we have a .code-profile that's editable. That's acceptable, right?

What if we took that .code-profile and put it into .vscode and had a little popup asking if you want to switch to the project profile. Would that be okay?

And what if instead of having a separate profile file, we just embedded that JSON structure directly into the extensions.json file? Would that be okay?

Which step here is going too far?

[IronGeek]

@TonyGravagno even with this setup:

The .code-profile file can be saved in a project repo for use with that specific project. You can create a separate repo with all profiles for all projects, which can be pushed and pulled so that the team can always get the most recent updates to all profiles.

The configuration (profile) wont be automatically applied until users/ devs applied it in their own box... if and only if the users/ devs choose to apply it...

[TonyGravagno]

;TL/DR; This ticket can't be processed because it's not specific enough

If we were the technicians processing this request, a clear question would be "what exactly do you want?". There are different use cases here, and so far no one-size fits-all solutions. Seeing this condition, I created a different ticket that requested a change that resulted in a solution for many use cases for this ticket. That was my approach and it was successful. We didn't get a solution for all use cases, but with a separate ticket we got a solution for some. I'm hoping (just as another dev doing my part to support the FOSS ecosystem) that some of you will find similar joy with a similar approach. I'll point out that after almost six years this ticket has not been resolved because there is no clear definition yet of "what exactly do you want?" So each person presents their use case and our friends at Microsoft are left to try to figure out how to make changes that they think will work for most of us. Meanwhile they actually did create a Profile system (that so far gathers as many 👍 as 🤔).

Failing to encourage you guys to try to use the solution that we just got to solve some of your long-term challenges, I'm suggesting you create separate tickets that directly address those challenges, being more explicit than "enable/disable extensions from config file". Why? Because that worked for me and i hope it works for you.

;TL/DR; Details about why this ticket is inadequate

- Which config file? Extensions.json wasn't designed for this. Code-workspace? So you're OK with duplicating extension specs in all of your projects? No? So you want a different dedicated file? Well, that's Code-Profile. - And you want it to be in a repo but you don't want people to mess with it. And you don't want to use a separate repo which is the normal way to handle that situation. - How does the team admin manage a ...profile-like-thing... for all workspaces in a category? Do we need some tool for that, maybe a new VSCode UI? Do new settings get pushed out to all repos or all dev workstations? Or is the detail centralized in a network resource or dedicated repo? - And you want it to auto-load and auto-update like .code-workspace? You can do that with a CLI directive : have your people click a bat/sh file rather than clicking the .code-workspace. They can't can't do that? Um, OK. - And should the developer be asked to replace their extensions? What if they say no? - Oh, don't ask - OK. If the environment changes for a developer, what happens when they exit the project? Do they go back to a default ... Profile? - What if they load a different project that hasn't been curated like the others? Do they need to do something like, uh, load some standard Profile or something? Be specific about what YOU want in another ticket so that your needs can get fresh eyes. None of us would want to process this awful ticket. I can't imagine anyone on the Microsoft team (or an independent contributor) feeling good about taking this one on either.

Trying to be more constructive: might this be a definition that satisfies what you guys need?

;TL/DR; Details for new ticket, comments sought

1. Add an option in Profile Save to save .code-profile without JSON stringification. 2. The .code-profile load should recognize non-stringified data on read. 3. As .code-workspace changes take effect immediately on save, so should extension enablement: a. In .code-workspace add a new array node named "profiles". Element objects in this array describe individual .code-profiles. b. Each element has a value "file", which is a relative or absolute file name/path to a .code-profile. c. Each element has a value "enabled", which specifies if that file is to be used. d. Profiles can contain settings, extensions, snippets, key shorcuts, and other details. The "profiles" node can specify any number of .code-profile files that include any of these details. The files aggregate the settings desired for an environment into a virtual profile for the current workspace. 4. Avoid losing existing workstation settings: a. On loading a .code-workspace with enabled "profiles" elements, VSCode will auto-save a .code-profile to avoid losing existing settings. b. The next workspace, or non-workspace folder or file, loaded without explicit profile settings will save the current profile and re-load the last auto-save. 5. Avoiding developer corruption of .code-workspace files, repo protection: a. The admin can add another element object on the "profiles" array with a single value "allowSave". If this .code-workspace:profiles:allowSave value is false, VSCode will not allow the save of the .code-workspace file. b. A similar lock value will be placed in .code-profile files so that team members cannot accidentally update them. To update a .code-profile, edit the file and set allowSave to true, save, use the UI to manipulate the config, then manually reset to false. This value should always be saved near the top of the .code-profile JSON for easy access. 6. Extensions.json is a user-level file but needs to be saved with the profile and workspace files to ensure consistent versioning at all times for all team developers. a. This is another "file"/"enabled"/"allowSave" set of values that can be set by the team admin. b. If not allowed yet, extensions.json must be allowed to be loaded from a location other than the user workstation profile folder. c. Since extensions.json links to workstation-specific resources (location:path), the paths in a team config file must be set to point to a network-accessible resource. 7. Developer workstation permission: a. Another "profiles" element object can be created with value "permission". If set to true, a single prompt is displayed to the developer to ask permission to change the environment for the currently loading workspace. If the developer says No, the workspace closes with no changes. b. If more versatility is desired, each .code-profile file specified can have a related "permission" value. For example, when loading extensions through the profile, the developer will not be asked for permission, but the team admin might give devs permission to avoid loading "recommended but not mandatory" keyboard shortcuts or snippets. 8. Longer load time: a. With extensions possibly being pulled across the network and being reconfigured with each project or project category, a new "please wait" progress bar needs to be clearly displayed to the developer to advise them that delays are expected. b. The environment should probably go into a dim mode to avoid interaction while this operation is in progress. 9. The team admin may want to implement a policy where the .code-workspace in branches allows dev permissions but commits to master force the permissions to false before commit. 10. With .code-profile file(s), extensions.json, and .code-workspace all pushed in commits to a repo, re-opening a repo from an old commit should result in the same environment configuration as when the commit was first pushed.

Offer suggestions for change and I'll modify this text.
Or be specific about use cases that this proposal does not address so that perhaps another solution can be proposed.
Or offer a similarly detailed solution that addresses your own use-cases, and be sure to address nuances where your use case fails for others discussed here so far.

[IronGeek]

@TonyGravagno First of all, I'm not trying to be rude or anything here, but clearly we have different use case, so please stop trying so hard to lump us all in your basket...

The fact that your problem could be solved by .code-profile is good for you, but for others and me included, .code-profile does not addresses our problem.

;TL/DR; This ticket can't be processed because it's not specific enough

The issue is already specific enough, otherwise the Team would've close this ticket a long time ago... 5+ year is more than enough time for the Team to request for clarification...

;TL/DR; Details for new ticket, comments sought

That seems overly complicated... with write locking, permission, etc. IMO, writing is not required, VS code only need to read the configuration and apply it, thats it. No writing needed, no export/ import needed... at least for this current issue.

Writing the configuration could be done manually outside of VS Code (or inside VS Code using its plain text editor). Same goes with write permission and or commiting to repo, VS Code doesn't need to know/ care about that...

If I were to (re) propose a suggestion, this could be done by extending extensions.json from:

{
  "recommendations": ["dbaeumer.vscode-eslint", "esbenp.prettier-vscode"]
}

to:

{
  "recommendations": ["dbaeumer.vscode-eslint", "esbenp.prettier-vscode"],
  "enabled": ["ms-python.python", "ms-toolsai.jupyter"],
  "disabled": ["ms-python.vscode-pylance", "ms-vscode.cpptools"]
}

1. VS code would read the extensions.json file automatically AS IS (it already read the file to retrieve recommend extensions) and use the enabled and or disabled values to create a SET of extensions to load/suppress depending on users already installed extensions.
2. If the extensions defined in enabled prop is installed and enabled then VS Code would do nothing
3. If the extensions defined in enabled prop is installed and not enabled, then VS code would enable that extensions
4. If the extensions defined in enabled prop is not installed then VS code could pop a warning that an extensions is needed to work with the current workspace
5. If the extensions defined in disabled prop is installed and enabled then VS Code would disable that extensions
6. If the extensions defined in disabled prop is installed and not enabled OR is not installed then VS Code would do nothing
7. The rest of the flow could continue AS IS... I think...

Again, I'm probably oversimplifying things here...
I'm sure there are a lot of things and implementation details that needs to be accounted for... But TBH, I always thought that the solution would by as simple as that...

[TonyGravagno]

Thanks again for your patience. 😉 OK, so this is all about extensions.json...

@sandy081 has said:

Extensions recommendation file is meant to be shared (in team). Disabling and enabling extensions is user specific. Merging these two is not a good idea I guess.

The thinking on that original design concept needs to change before implementing enable/disable in extensions.json. Sandy are you guys there yet? Or are you tending toward using a different mechanism so that extensions.json doesn't need to be redefined? I'd guess the latter would be easier and preferable?

@IronGeek Are you just suggesting surfacing the list of required/forbidden extensions in extensions.json for all projects? Some use cases describe a per-project extensions list.

One solution for per-project settings, not universally acceptable, is that there are CLI options to select the user folder. By changing the code command/shortcut, or opening a bat/sh file, a specific team folder can be selected where the extensions.json defines project-specific requirements. For those who could use this, note that from the CLI you can disable all extensions and then enable just the ones that are approved - or enable/disable exactly as described for extensions.json.

Another often-requested solution that could be implemented for project-specific settings with extensions.json is .vscode/extensions.json. The presence of this override/requirements file would preclude the need for changes to the existing file which was designed for recommendations. This does bring up noted VC concerns, but it's yet another alternative solution where others might not apply.

If "The rest of the flow could continue AS IS... I think..." we still need to consider how existing Enable/Disable per-workspace settings are applied. I think the idea of this ticket is to surface those settings as well, out of "local settings" (which is often referenced but I have no idea where that is). If those per-workspace settings are persisted to extensions.json, then we have that write/lock and maybe VC issue to consider. If not, then there will be two versions of the truth in a session - the enable/disable in extensions.json, and the local settings. The code smell starts to get unpleasant.

What happens if a dev chooses not to accept the enable/disable directives? And, is a dev allowed to reset their extensions after loading a project? It kinda depends on how strong this directive is intended to be - is it a mandate or a recommendation? That is, are the enable/disable settings checked for compliance at the end of the startup process or whenever the dev attempts to change extension configs? If so, that's a new requirement, not "as is" processing.

If usage of extensions.json requires any interaction from the developer, or some knowledge of protocols (like don't change your settings or don't commit settings if you change them), I'll note that this has already been discussed and deemed unacceptable by some. Profiles already have the extensions enable/disable settings in plain text, but are unacceptable for some because they require either using a bat/sh Or manually selecting a profile based on an understanding of the project.

There have also been suggestions to augment extensions.json (or a similar config file) with language-specific requirements, so that team members will use the same extensions for all projects that include specific languages. For some, this may eliminate the need for project-specific configs. An ideal solution should include this concept as well, or similar versatility to avoid having to revisit this topic later with yet another "yeah but that solution Still doesn't address these use cases...".

For scenarios where a single global directive doesn't apply, how does the dev get back to their own default extensions.json? This would be another use case that may not be served by the proposal.

There is another concern that I've only seen expressed by a few people in all of these tickets on this topic - extension versions. In my proposal I detailed storing extension versions with a project so that when forking or branching from an older tag we will get the extension version that was used with that commit. Otherwise we might enable the same extension, but with a more recent version and settings, we might introduce changes that aren't compatible with the original. If just the extension name is saved in a .vscode/extensions.json or similar file which is in VC, an old project may require an extension that is now no longer available or temporarily bugged. This is DLL Hell all over again, solved in .NET and by modern package management tools. We all know about versioning and dependency issues, and a simple proposal with extension names doesn't address this at all.

Writing the configuration could be done manually outside of VS Code (or inside VS Code using its plain text editor). Same goes with write permission and or commiting to repo, VS Code doesn't need to know/ care about that...

I completely agree that VSCode shouldn't have to deal with such things. I think the whole idea here is that we just want all settings to be available in common JSON files. I'll add that a natural request that we can expect is for a UI to maintain any new configuration detail. There is already a UI for enable/disable extensions, and a UI for extension selection for profiles. Will we ask for a third for what seems like the same purpose just approached from a different vector? That's just asking for more smelly code.

I believe the current change proposal for extensions.json will not satisfy a significant number of requirements, and I think more detail or a different solution is required. How tolerant is this user base for a platform that has different notions of the same concept, bolted on over the years? I think the Microsoft team is fine with big new features, but they have a resistance to inelegant solutions - and as a user/developer so do I. I don't think there is a "simple" solution to this without messy hacks that can't be pulled out later. I think we would all prefer a more elegant solution so that we and others don't see this as a massive cludge over time. The challenge is to achieve that elegance without ripping apart a lot of stuff that works now. That takes a lot of time and I suspect that's what has made this a lower priority task despite a lot of related tickets and hundreds of confirmations of need.

I'm absolutely not trying to be argumentative, just trying to nail down an acceptable and actionable proposal that we can ask the team to prioritize.

[TonyGravagno]

Reducing down to a 2-point simple solution :

1) Ensure .code-profile files are not stringified. 2) Allow for a new vscode_default.code-profile to be auto-loaded prior to extensions.json from the same folder that contains extensions.json.

Implementation

This essentially sets a default value for the --profile CLI option. Right now there is no default set for that parameter. (❓) Any existing --profile directive will override.
Do not prompt the user when reconfiguring with this file. On completion of the load, process extensions.json as always with no changes.

@sandy081 Do you see anything wrong with this? Will this help to close other tickets?

Benefits

• Can probably be done quickly.
• Addresses many/most?/all? use cases.
• Does not affect or break any existing installation.
• The extensions.json file doesn't need to be redefined.
• Does not require any new functionality. No enhancements need to be suggested for workspaces, or protection against user changes. Profiles can already be associated with workspaces for those who wish to do so, with centralized configs, user-specific configs, or in-project configs saved in VC.
• Satisfies the requirement for auto-loading with no user intervention.
• Code is already in place for profile merging, so adding a project-specific config over a default should not present any new challenges.
• No UI changes (?).

Not addressed

• User editing or saving over a default. Can only be done manually and with intent. Not a unique concern.
• Modifying the config file with the editor or externally does not auto-reconfig the environment. Process in a separate ticket.

[l-inc]

@TonyGravagno, sorry to add on top, but I don't think the profiles solve the problem in our environment either.

Long story short (see the paragraph below for the long story), the selection of extensions (such as those specified in the profile) must not yet be applied when VS Code starts in our environment. The selection of extensions for a given project should only be applied, once the project (represented by its "xyz.code-workspace") is opened from within VS Code.

Our development environments each encompass a few dozens of projects each tracked in separate repositories (mostly, with C, python and go code, but also various documentation and other kinds of repositories). The whole ensemble works together with lots of inter-dependencies. This is all managed via google repo manifests (again, a separate repository by design). Because of the relatively deep directory tree (but also for other reasons), it is useful to track VS Code configurations ("*.code-workspace") for all the projects in a single repository out-of-tree with respect to their respective projects (that is, in a yet again separate repository). That's where the extension "Workspace Explorer" happens to be very helpful in listing all the projects by iterating over "*.code-workspace" in a given directory sub-tree. That's the only extension I found that can be configured without specifying absolute paths (which is crucial for sharing among colleagues).

[IronGeek]

@TonyGravagno IMO, this is exactly why this ticket exist (emphasis on the bolded text).

If "The rest of the flow could continue AS IS... I think..." we still need to consider how existing Enable/Disable per-workspace settings are applied. I think the idea of this ticket is to surface those settings as well, out of "local settings" (which is often referenced but I have no idea where that is). If those per-workspace settings are persisted to extensions.json, then we have that write/lock and maybe VC issue to consider. If not, then there will be two versions of the truth in a session - the enable/disable in extensions.json, and the local settings. The code smell starts to get unpleasant.

The problem with the current VS Code extensions enablement mechanism is that the settings is saved in local storage cache, both for the globally enabled/disabled extensions and the per-workspace enabled/ disabled extensions

https://github.com/microsoft/vscode/issues/15611#issuecomment-349231959

I think its fine to save the settings that way for the globally enabled/disabled extensions, but for per-workspace enabled/ disabled extensions, saving it to local storage cache makes the settings not portable. If I've sets the enabled/ disabled extensions in my workspace (project/ repo) in machine A, that settings is not mirrored in the same workspace (same project/ repo) in machine B.

[TonyGravagno]

@l-inc - Actually, profiles do apply themselves to the current workspace when it is opened. I mean, it would be useless if we load a profile at VSCode startup for a PHP project, switch to a JavaScript project, and we're still running all the PHP extensions (um, which is exactly what we have when not using profiles).

In front of me right now (screenshot), I have a TypeScript/MySQL project from a newly forked repo. VSCode doesn't know what profile to apply to it so it uses my Default, which happens to include extensions for Java, PHP, .NET, and others. I just opened a .code-workspace for an in-progress React/TypeScript project and the profile for that changed to my React TS profile. Note different extensions installed and/or disabled.

Click, I just associated the TS project with another TS-specific profile rather than the PHP-oriented Default. (Oops, click, I also needed to remove the .NET Install Tool for Extension Authors from my React TS profile, though it's still in Default - compare with above.)

As seen, it does know to use the React TS profile for a recognized workspace. I don't know where that workspace>profile link is stored, but it should be surfaced, which is why my proposal above included specifying .code-profiles in the .code-workspace file (and thus "enable/disable extensions from config file").

If you have actually tried to create profiles for different projects, and they really do not work as you wish, then perhaps you could explain exactly what verifiably does not work so that Microsoft can consider a remedy. (Others with different use cases have already done this.)

[l-inc]

@TonyGravagno, I was replying in the context of your proposal to start VS Code with a command line that includes the distributed profile. If you assume the context, in which the profiles are already imported, we are back to the problem that all the profiles (per each of the dozens of projects) need to be (re-)imported first.

which is why my proposal above included specifying .code-profiles in the .code-workspace file (and thus "enable/disable extensions from config file")

Sorry, but I'm unable to find this proposal above (even after the third look). I only see your proposals around the use of the command line and the auto-loading of a default profile. If you now propose auto-loading the profiles via references within ".code-workspace", this would fulfill the request, but if we ask to add a feature anyway, then specifying the plugins (enabled and disabled) directly in ".code-workspace", analogously to how they are already specified in "recommendations", is a cleaner solution than piggy-backing the complete profiles, which can remain a feature for personal overrides.

[TonyGravagno]

@l-inc Please see the proposal in this comment - open the ;TL/DR; accordion with Details.

All - I've done my FOSS bit here and don't have anything new to contribute, so I'll back out now. I hope you find your solutions.