Support machine-specific settings that can be set (overridden) in workspace/folder

[DanTup]

When trying out the remote/container support in Insiders, I noticed some issues caused by my SDK paths being synced from Windows into the container. I saw in 1.24 there's a new machine scope for settings that seems like it's designed to fix this.

However, many of my paths (SDKs, log files) are window-scoped, so that they can be set both global or per-project (for example, you might set an SDK path in user settings, but want to override it for a specific folder).

In order to prevent the global user SDK path being synced to the container, we need to change the scope from window to machine, however that prevents a (non-remote/container) user from being able to set the SDK at the workspace level (they'll get warnings "This setting can be applied only in user Settings").

This doesn't seem very flexible - it seems like we should be able to have settings that can be set both at the user-level (and considered machine-specific) and also at the workspace/folder level (where it's up to the user to manage).

Note: I am not asking for machine-specific workspace settings. If a user chooses to set these settings in the workspace level, it's on them to make sure they work on whatever machine/container they open the settings on. What I think is required is:

• Can be overridden at a folder level for a non-remote user
• Can be set at a machine level but is not synced into containers/remotes

I guess it's similar to the typescript.tsdk setting, however by coincidence that's usually set to a relative path (node_modules) so the issue isn't as obvious there. If people set absolute paths there, then they'd hit this same issue (if they set it in user settings, it would sync into containers and potentially be wrong, and if it was marked as machine, it would no longer be settable at the folder level).

[sandy081]

@DanTup Here is how different scopes work in a remote window

scope ↓ / target →	user	remote	workspace	folder
application	✔️	✖️	✖️	✖️
machine	✖️	✔️	✖️	✖️
window	✔️	✔️	✔️	✖️
resource	✔️	✔️	✔️	✔️

Machine scoped settings are prevented at workspace/folder level because of the reason that machine scoped settings are mostly with paths and having such settings shareable does not makes sense.

However, many of my paths (SDKs, log files) are window-scoped, so that they can be set both global or per-project (for example, you might set an SDK path in user settings, but want to override it for a specific folder).

How does such settings work when the project is shared as all users might not have same common paths. May I know more about such settings to understand and see what is the right approach to take?

[DanTup]

Machine scoped settings are prevented at workspace/folder level because of the reason that machine scoped settings are mostly with paths and having such settings shareable does not makes sense.

I think it makes perfect sense, if it wasn't for VS Code not making it easy to not commit them :-)

For example, in my global settings I have:

• dart.sdkPath: ~/Dev/dart-sdk/stable

Then I open a project I'm working on that uses new features that I want to use a bleeding-edge SDK for. I override the sdk path in the workspace settings:

• dart.sdkPath: ~/Dev/dart-sdk/bleeding-edge

This all works fine today (and my extension provides a quick-pick list to quickly switch between SDKs for the current project, which is writes into workspace settings) until you remote.

This is good functionality - the only thing that makes it weird is that VS Code doesn't separate workspace settings that we do and don't want to commit (that's what #40233 is asking for).

TypeScript has exactly this setup (typescript.tsdk) however it's fortunate that it's always a relative path so they're not hit by this issue. If you wanted to set typescript.tsdk to an absolute path, you'd have the same problem.

How does such settings work when the project is shared as all users might not have same common paths.

Right now, my assumption is that if people put SDK paths in their workspace settings, they would not commit them (or they would be the only people working on their project). This isn't a perfect solution, but until we have something like #40233 it's unavoidable.

I actually think #40233 is a better fox for this, if you consider them "machine-specific workspace settings". Eg. put them in settings.machine.json and then people can gitignore them, and you can also ignore them when remoting.

[sandy081]

Good that we share same thinking for solving this. I too agree that the right fix for this is to support local workspace settings. Remote set up adds more weightage for this requirement.

Making this dup of #40233

[vscodebot]

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for existing issues here. See also our issue reporting guidelines.

Happy Coding!

[DanTup]

Potentially :) I'm sure there are some users that also want local workspace settings that will apply in remotes (for ex. some have extensions that change colours of VS Code to make each workspace distinctive - they probably do want them to apply remotely).

I still sorta think that putting machine into scope may be the wrong call, and settings should probably be able to be flagged as machine-specific (eg. they're paths) in addition to being set as application/window/resource 🤔

[sandy081]

Is there any example do you think of?

[DanTup]

I was thinking of https://github.com/johnpapa/vscode-peacock, though now I think about it, that's a UI extension that runs in the client, so presumably it would still see the "local workspace" settings even though they're not synced to the server? Or do the same rules apply for which settings are seen for both ends?

[sandy081]

Non shareable workspace settings would be associated to the workspace/folder and they will have same rules as of now except that machine scoped settings will be respected in non shareable workspace settings.

[DanTup]

I'm not sure I understand. Let's say the linked issue above is implemented, and we end up with .vscode/settings.json and .vscode/settings.local.json (the idea being the user commits .vscode/settings.json but gitignores .vscode/settings.local.json).

If I add "foo.bar": true to .vscode/settings.local.json, would it be seen by:

a) remote running extensions (eg. like my debugger)
b) local UI extensions (eg. like Peacock)

If the answers are a) No and b) Yes, then I think that satisfies both the needs above. However if they're both the same answer, I think either it won't handle my use case, or won't handle Peacocks :(

[sandy081]

true value for foo.bar is seen by all (both remote and local) extensions. May I know why it wont handle your usecase or other's?

[DanTup]

I have a setting that is an SDK path. It needs to be:

1. Settable in User Settings (so the user can set the SDK once and it works for all projects)
2. Overridable in Workspace Settings (so the user can switch to a dev SDK - or even an older SDK - for a specific project)
3. If set in User Settings, not applied to a remote session (which may be a different platform)

This is not possible today, and based on your last comment seems it won't be possible even if "local workspace settings" are implemented.

In order to do 3 I have to mark the setting as "machine scope", but then 2 doesn't work because VS Code complains if you try to set a machine-scope setting at a workspace level (the validation tells you not to set a machine-scope setting here).

I don't understand why a setting can't be machine-scoped if set globally, yet still overridable at a workspace level.

[sandy081]

I think we agreed that non shareable folder settings is the solution for your usecase:

A path setting which is recommended to be machine scope:

1. If set in User settings applied to all local folders
2. If set in User Settings, not applied to a remote folder
3. If set in Non Shareable Folder Settings applies to the associated folder
4. Not allowed to be set in shareable folder settings

A common SDK path can be set for all local folders using User settings
A common SDK path can be set for all remote folders using Remote settings
A specific SDK path can be set for a specific folder (local/remote) using Non sharable folder settings

Even the Peacock extension can configure window specific settings like themes, colors in non sharable folder settings which are associated to the given folder.

I don't understand why a setting can't be machine-scoped if set globally, yet still overridable at a workspace level.

It makes sense to be overridable only if the setting is not shared. Sharing a machine scoped setting does not makes sense.

Sorry, if I am missing or not understanding some thing which you think that does not work with non shareable folder settings.

[DanTup]

Even the Peacock extension can configure window specific settings like themes, colors in non sharable folder settings which are associated to the given folder.

But wouldn't Peacock want those settings to apply when when in a remote session? Eg. I set my color to "red" in the non shareable folder setting for my project, then I open it in a container - I still want it to be read, so the setting still needs to apply (at least in the client)?

(My understanding from this comment was that the client and server would always see the same settings, which sounds like Peacocks non shareable color settings would not have any effect when connected to a container?)

[sandy081]

But wouldn't Peacock want those settings to apply when when in a remote session? Eg. I set my color to "red" in the non shareable folder setting for my project, then I open it in a container - I still want it to be read, so the setting still needs to apply (at least in the client)?

Right, opening a folder on disk locally or in container will have different non shareable settings as they are two different folders with different URIs. I think this limitation is ok and if needed we can think of letting dev container extension syncing these settings (but as said I would not go to that unless really needed).

[DanTup]

Ok, then it sounds like the non-shared settings will work for me if the local/remote won't share them by default. When can we have it? 😆

[sandy081]

Reopening to bring it up for discussion to allow a machine scope setting to be overridable and sharable.

[mgood]

I still sorta think that putting machine into scope may be the wrong call, and settings should probably be able to be flagged as machine-specific (eg. they're paths) in addition to being set as application/window/resource 🤔

I agree that it would be useful to separate the concepts.

In microsoft/vscode-go#2576 several settings for Go were changed to be machine scope. However, this broke our company's shared workspace settings. We use the workspace settings to configure workspace-relative paths where we have the Go SDK and Go libraries installed.

Our current config is mostly turn-key where a dev can check out the repo and get started with VSCode with very few manual steps. Configuring those paths in the User Settings would not only make our developer setup less convenient, but also means that developers can't easily work on multiple Go projects with different configurations.

This is a different use-case than #40233 since these are shared settings committed to our repo, rather than being able to provide user-specific overrides (though I would love to see that implemented as well).

[sandy081]

Introducing a new scope machine-overridable to enable machine settings to be overridable. Here is the summary of the scopes

• window -> that can be configured till window level and cannot be overridden further
• resource -> that can be configured till resource (folder) level
• machine -> that can be configured at machine level (local / remote) and cannot be overridden further.
• machine-overridable -> that can be configured at machine level and can be overridden further

Calling it machine-overridable but if there is a better name that apts, open to it.

[DanTup]

Sounds good to me :-)

[sandy081]

Verify that a configuration contributed with scope machine-overridable can be overridden as follows

• In Local Window, it can be overridden at all levels (User, Workspace, Folder)
• In Remote Window, it can be overridden at following levels (Remote, Workspace, Folder). It cannot be overridden in User Settings.

[aeschli]

In Remote Window, it can be overridden at following levels (Remote, Workspace, Folder). It cannot be overridden in User Settings.

Doesn't seem to work for me. Created #79983.

I suggest the issue is tracked there, marking as (partially) verified.