Repository navigation
Support machine-specific settings that can be set (overridden) in workspace/folder #73985
Description
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).
Activity
[-]Support machine-specific settings that can be set in workspace/folder[/-][+]Support machine-specific settings that can be set (overridden) in workspace/folder[/+]sandy081 commentedon Jun 3, 2019
Danny Tuppeny (@DanTup) Here is how different scopes work in a remote window
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.
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 commentedon Jun 4, 2019
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/stableThen 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-edgeThis 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 settypescript.tsdkto an absolute path, you'd have the same problem.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 commentedon Jun 4, 2019
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 commentedon Jun 4, 2019
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 commentedon Jun 4, 2019
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
machineintoscopemay be the wrong call, and settings should probably be able to be flagged asmachine-specific(eg. they're paths) in addition to being set as application/window/resource 🤔sandy081 commentedon Jun 5, 2019
Is there any example do you think of?
DanTup commentedon Jun 5, 2019
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 commentedon Jun 5, 2019
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 commentedon Jun 5, 2019
I'm not sure I understand. Let's say the linked issue above is implemented, and we end up with
.vscode/settings.jsonand.vscode/settings.local.json(the idea being the user commits.vscode/settings.jsonbut gitignores.vscode/settings.local.json).If I add
"foo.bar": trueto.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 :(
9 remaining items
sandy081 commentedon Aug 16, 2019
Introducing a new scope
machine-overridableto enable machine settings to be overridable. Here is the summary of the scopeswindow-> that can be configured till window level and cannot be overridden furtherresource-> that can be configured till resource (folder) levelmachine-> 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 furtherCalling it
machine-overridablebut if there is a better name that apts, open to it.DanTup commentedon Aug 19, 2019
Sounds good to me :-)
sandy081 commentedon Aug 26, 2019
Verify that a configuration contributed with scope
machine-overridablecan be overridden as followsaeschli commentedon Aug 28, 2019
Doesn't seem to work for me. Created #79983.
I suggest the issue is tracked there, marking as (partially) verified.