Allow to scope settings by platform

[jarod51]

Hi

I develop on 3 different platform. When synchronizing settings, snippets and so on, i often must change path, adjust font-size, etc...

So, it could be great if we had a per platform settings set (Windows, Mac, Unix)

[yzhang-gh]

I can see that this issue was opened long before we had the official Settings Sync feature. But as it is tagged with settings-sync now, I'd like to raise a discussion in relation with #92393 (allowing to sync multiple settings profiles).

IMHO, this feature (settings by platform) is in the subset of #92393 (multiple profiles). There may also be cases that users need multiple profiles even for a same platform (e.g., for work and for personal devices).

[Natetronn]

@yzhang-gh it would be great if this was built in! Most of the solutions I've found have been less than ideal.

[wolf99]

@yzhang-gh Totes, implementation of the feature request on #92393 would implicitly encompass this use case I believe

[veeara282]

@yzhang-gh it would be great if this was built in! Most of the solutions I've found have been less than ideal.

Same. For my current project, we have a settings.json file tracked in the Git repository and need it to have different python.pythonPath values for each OS. I'd like to be able to use one settings file across multiple platforms with no extensions.

[chri7325]

@aidan-fitz we have the the exact same problem. The same goes for the python linter and formatter path. Our workaround is to use unix as the default and then have the Window's developers set their global configuration for those but it is confusing at first.

[H-G-Hristov]

I just run into that problem. We have /src directory that is shared with a docker container which mounts the same directory. It turns out that on the host .vscode is the same directory as seen in the container so I cannot use VSCode for both. Maybe the best option would be to have a subfolder for each platform. So that all files launch.json, c_cpp_properties.json can be independent. Maybe something like:

      .vscode/configurations.json
      .vscode/Windows_01/settings.json
      .vscode/Windows_23/settings.json
      .vscode/Windows_23/launch
      .vscode/Linux/settings.json
      .vscode/Linux/c_cpp_properties.json

configurations.json -> points the the correct subdirectory to use, which can be configured by default or selected from within VSCode:

{
     {
          "configuration" : "Windows 1",
          "relativePath" : "vscode/Windows1"
     },
     {
          "configuration" : "MacOS 23",
          "relativePath" : "vscode/darwin23"
      }
}

[brunoamancio]

Happy birthday, issue 5595! I wish you success and hope to see you again in 10 years, when you are closed.

[Tyriar]

New requirement for this from https://github.com/microsoft/vscode/issues/45444, we would still want platform-specific defaults for this ideally that would be filled in. ie. say you autocompleted:

`[isWindows]`: {
  "terminal.integrated.profiles"
}

It should fill in the Windows-specific defaults (git bash, cmd, powershell).

[taikulawo]

@Tyriar When this feature will be in next release :), 5 years old. I try use "[isWIndow]":{}, but don't works

[MostHated]

Agreed, this is increasingly and ridiculously necessary along with being able to read from environment variables within the settings.json. I could argue that being able to read env variables within settings.json could almost fill in the need for this issue, just in a roundabout way.

Ex. "editor.fontFamily": "${env:fontsFromSpecificSystem}" As it could then be different not only per OS type, but even between multiple systems of the same OS type.
Either way, both are needed something fierce.

It's not like it can't be done.. We see it in other aspects of the application, be it Tasks, or whereever. It's there, it works.

Tasks has:

"linux": {
    "command": "/mnt/x/GitHub/instance-id/FormatComments/build/fcomment",
},
"windows": {
    "command": "C:/files/fcomment.exe",
},

And it also has:

{
  ...
  "cwd": "${workspaceFolder}",
  "args": ["${env:USERNAME}"]
}

So, seriously, whats the deal?

[Tyriar]

The deal 👇

I don't believe this is on the 2021 roadmap, keep voting though as that increases the visibility of the issue.

[1raghavmahajan]

keep voting though as that increases the visibility of the issue.

@Tyriar Could you point out where should we vote?

[MmAaXx500]

@1raghavmahajan On the first post with a 👍

[alo0oz]

Still waiting for this................

[KarFan-FS]

+1

[Sv3rk3r]

This must be a fundamental functionality that really needs to be implemented soon!

[Sv3rk3r]

Honestly, I need to have two different workspace files, one for windows and the other for Linux, while all other VS code files can handle both environments.

[grrowl]

Would love to see this feature, ideally similar to how colorCustomisations are specified:

{
  "workbench.sideBar.location": "left",
  “[web]”: {
      "workbench.sideBar.location": "right",
  }
}

[JRHeaton]

I use a small Mac laptop and a huge dual-screen Windows setup at different times, it would be very nice to be able to apply settings per-platform, such as font size, and scrolling speeds. Additionally, the ability to control which extensions are enabled per-platform, as I have no intention of using PowerShell for example on macOS, and needn't be told it's not installed each time I open the program on Mac.

EDIT: Thanks for the unexplained, pointless downvote on an opinion post. You're super cool.

[pouyarezvani]

2021 🙄 I'll check back in 2022 🥱

[gvcallen]

@pouyakary with you on that one. any extension with a setting which is directory-based essentially cannot have that setting synced due to this issue. :( one can hope

[pouyakary]

@gvcallen sorry I don't understand what are you mentioning. Can you please explain a bit more?

[MostHated]

// Can't sync this setting, because many of us use a mix of Linux, Windows, and Mac for Work or Home
// and if we do sync it, it will be wrong on other PC's that are different Operating System
{
    "customExtension.requiredPath": "/path/that/is/needed",
}

This is what we need. A way to define OS-specific values to necessary parameters

// 
{
    "if.os.Windows":[
        "customExtension.requiredPath": "C:\\User\\MyUser\\path",
    ],  
    "if.os.Linux":[
        "customExtension.requiredPath": "/home/user/path",
    ],

}

Similar to how in C# you can use compiler definition so that you can use the same variable names and not break code

#if Windows
    var myPath = "";
#elif Linux
    var myPath = "";
#else Macos
    var myPath = "";
#endif

or like this:

using System.Runtime.InteropServices;

public static class OperatingSystem
{
    public static bool IsWindows() =>
        RuntimeInformation.IsOSPlatform(OSPlatform.Windows);

    public static bool IsMacOS() =>
        RuntimeInformation.IsOSPlatform(OSPlatform.OSX);

    public static bool IsLinux() =>
        RuntimeInformation.IsOSPlatform(OSPlatform.Linux);
}

// Then this can be used:

if (OperatingSystem.IsLinux())
{
    Console.WriteLine("This code works only on Linux");
}

if (OperatingSystem.IsWindows())
{
    Console.WriteLine("This code works only on Windows");
}

[Natetronn]

I hate to mention this extension, because I want to see this feature come to fruition and I don't want its existence (or others similar, which I could never get to work) to be used as an excuse for such a needed FR, but I thought some of you might find it useful, at least while you wait:

https://marketplace.visualstudio.com/items?itemName=runarsf.platform-settings

[MostHated]

Like you, I have tried that plugin, and any others I could find, and the hassle, or often overall ineffectiveness of them are why I am here once again bumping this thread.

[gvcallen]

@pouyakary essentially, if I have an extension that has a setting which is a folder path (let's say, a directory to a bunch of project templates), then I cannot successfully sync this setting without issues, because folder paths are fundamentally platform independent. Overall, any setting storing a folder path has to be synced manually

[pouyakary]

@gvcallen I think you've confused me for someone else. I don't contribute to the extension settings of the vscode. I though somehow it can be related to my extensions but I don't have any extensions that have user settings.

[pouyarezvani]

I use a Mac at work and Windows PC at home. And I wanted different terminal fonts because of zsh and bash. That's why a platform-specific option would be amazing to have in VSCode. So per some people's recommendations, I installed the vs code extension Platform-Settings made by runarsf

It actually solves my problem. I do have to reload my VSCode each time I switch computers/platforms for it to catch the platform-specific setting. And for reloading I use this extension reload to reload VSCode with a click of a button.

//  ========== Platform Settings ==========
    "platformSettings.autoLoad": true,
    "platformSettings.platforms": {
        "win32": {
            "nodes": {
                    "terminal.integrated.fontFamily": "Menlo",
            }
        },
        "darwin": {
            "nodes": {
                     "terminal.integrated.fontFamily": "MesloLGS NF"
            }
         },
    },

But as @Natetronn mentioned, it's not a native experience and I hate to have to rely on extensions to do a job that is meant to exist in VSCode. But for now, this is a solution.

[wolf99]

You can use the following extension to achieve this: https://marketplace.visualstudio.com/items?itemName=Shan.code-settings-sync

I still happily use this daily, but sadly this extension is now seeing less contributions because the native functionally has taken over even though the latter only covers one use case.

[sandorex]

Could we please limit this to contributors or something as i keep getting notification for comments like 'I need this', i do not think it contributes to the issue and as it is not a priority you can just vote on the top comment and wait

[thernstig]

@sandersn agree, although I cannot understand why this is not a priority for the VS Code dev team, considering it is one of the most upvoted issues in this repo. Sometimes issue-prioritization for VS Code works in mysterious ways 😄

[Logicer16]

I cannot understand why this is not a priority for the VS Code dev team, considering it is one of the most upvoted issues in this repo

Take note of how the most upvoted issue ever for VS Code (#10121) was locked for the same reason @sandorex describes (https://github.com/microsoft/vscode/issues/10121#issuecomment-443602572) and then subsequently hasn't been updated for almost three years.

The dev team probably base their priorities off of more than just upvotes (and they should). I agree flooding the comments with 'plz do this' is unproductive. I'm certain this will be done eventually, but I've no clue exactly when.

[thernstig]

@Logicer16 that might be so, unless you look at this blog post https://code.visualstudio.com/blogs/2016/08/19/goodbyeuservoice written about 4 months after this issue was created.

And it was 5 years ago this was written. Of course they base it on more than this, but I'd think the upvotes has some bearing since it is their main form of user feedback.

We are side-stepping the topic here though.

[tishion]

I really need this feature. I always work on C/C++ projects for cross-platforms with CMake and I only keep one source repo on my machine and share them in different platforms. e.g.

1. I keep the project source on my windows machine and access the source in WSL
2. when I am working in Windows I need to configure the project with CMake then it will generate the build folder at ${workspaceFolder}/build
3. when I am working in WSL with CMake configure it also generate the build folder at ${workspaceFolder}/build
4. and then i go back to Windows I need to reconfigure it with overwriting the ${workspaceFolder}/build folder

In real project, i need to jump in Windows/Linux/macOS, this is really annoying.

if we can have platform specified settings.json, we can config the build folder as follows. "cmake.buildDirectory": "${workspaceFolder}/.build/{$platformName}"

[AbdulAbCellera]

I really need this feature. I always work on C/C++ projects for cross-platforms with CMake and I only keep one source repo on my machine and share them in different platforms. e.g.

1. I keep the project source on my windows machine and access the source in WSL
2. when I am working in Windows I need to configure the project with CMake then it will generate the build folder at ${workspaceFolder}/build
3. when I am working in WSL with CMake configure it also generate the build folder at ${workspaceFolder}/build
4. and then i go back to Windows I need to reconfigure it with overwriting the ${workspaceFolder}/build folder

In real project, i need to jump in Windows/Linux/macOS, this is really annoying.

if we can have platform specified settings.json, we can config the build folder as follows. "cmake.buildDirectory": "${workspaceFolder}/.build/{$platformName}"

One way I deal with this is by using the compiler in the path like "cmake.buildDirectory": "${workspaceFolder}/build/${buildKit}". I, also, sometimes, use environment variables to customize this between different OSs. For more variables to use: https://github.com/microsoft/vscode-cmake-tools/blob/main/docs/cmake-settings.md

[leodutra]

The app is multiplatform but closed requests about including a config for multiplatform. "Interesting."

[tishion]

I really need this feature. I always work on C/C++ projects for cross-platforms with CMake and I only keep one source repo on my machine and share them in different platforms. e.g.

1. I keep the project source on my windows machine and access the source in WSL
2. when I am working in Windows I need to configure the project with CMake then it will generate the build folder at ${workspaceFolder}/build
3. when I am working in WSL with CMake configure it also generate the build folder at ${workspaceFolder}/build
4. and then i go back to Windows I need to reconfigure it with overwriting the ${workspaceFolder}/build folder

In real project, i need to jump in Windows/Linux/macOS, this is really annoying. if we can have platform specified settings.json, we can config the build folder as follows. "cmake.buildDirectory": "${workspaceFolder}/.build/{$platformName}"

One way I deal with this is by using the compiler in the path like "cmake.buildDirectory": "${workspaceFolder}/build/${buildKit}". I, also, sometimes, use environment variables to customize this between different OSs. For more variables to use: https://github.com/microsoft/vscode-cmake-tools/blob/main/docs/cmake-settings.md

Hi @AbdulAbCellera thanks for sharing the useful experience, I will have a try!

[XuehaiPan]

I need this feature too to sync my settings across devices (cross platforms). There are many differences between Windows and Unix-like systems (macOS / Linux, etc.).

• The path separators (/ on Unix-like and \ on Windows) and delimiters (: on Unix-like and ; on Windows).

• The same program have different configurations on different platforms. For example, I need to set:

  • Linux: "python.condaPath": "~/Miniconda3/condabin/conda"
  • Windows: "python.condaPath": "~\\Miniconda3\\Scripts\\conda.exe"

  for my Python extension. Same situations for JAVA_HOME and GOPATH.

• Incompatible font families. I'm using nerd fonts for my customized shell themes. I need to set 'DejaVuSansMono Nerd Font Mono' on Linux, but 'DejaVuSansMono NF' on Windows.

[fredrikaverpil]

@XuehaiPan can you try setting e.g. an CONDA_EXEC_PATH environment variable on your systems and then use "python.condaPath": "${env:CONDA_EXEC_PATH}?

[XuehaiPan]

@XuehaiPan can you try setting e.g. an CONDA_EXEC_PATH environment variable on your systems and then use "python.condaPath": "${env:CONDA_EXEC_PATH}?

@fredrikaverpil it works but I don't think vscode (version 1.62.2) supports environment variable substitution in settings yet. See #2809.

---

I install conda in my home directory, and the Python extension will search for the conda candidate at startup (function getCandidatesFromKnownPaths()).

https://github.com/microsoft/vscode-python/blob/3698950c97982f31bb9dbfc19c4cd8308acda284/src/client/pythonEnvironments/discovery/locators/services/conda.ts#L109-L118

Actually, if you install conda in your home directory with the name xxxxconda, you do not need to set "python.condaPath" in your settings.

---

This is a special case the extension handles. I still want vscode support scope settings by platform feature.

[Absolucy]

Here's my use-case for this:

"windows": {
    "rust-analyzer.checkOnSave.extraArgs": [
        "--target-dir",
        "C:\\Users\\Lucy\\AppData\\Local\\Temp\\rust-analyzer-check"
    ],
},
"linux": {
    "rust-analyzer.checkOnSave.extraArgs": [
        "--target-dir",
        "/tmp/rust-analyzer-check"
    ],
},
"macos": {
    "rust-analyzer.checkOnSave.extraArgs": [
        "--target-dir",
        "/Users/Lucy/Library/Caches/TemporaryItems/rust-analyzer-check"
    ],
}

[OgulcanCelik]

my use case is like this:

To use specific fonts for editor and terminal, you have to use different values for font families.

i.e. to use Patched Hack Font, on Linux I need to use "editor.fontFamily": "Hack Nerd Font", but on Windows, I need to use "editor.fontFamily": "Hack NF Regular". I mean it's 2022 guys.

[philipbel]

A little over two months until the issue's 5th birthday. Can't wait 🥳

[H-G-Hristov]

launch.json by platform :)

[ThatGuyRussell]

@OgulcanCelik I have been able to get around the font family issue with: "editor.fontFamily": "Hack NF, Hack Nerd Font"

Since Hack NF isn't on my Mac it correctly falls back to Hack Nerd Font

[JRHeaton]

This issue feels like it has been up for a ridiculously long amount of time for how direct and obvious of a necessary feature this is for multi platform users. If you make a multi platform app, you must understand that not all software or settings are compatible. As developers I’d figure this is obvious. Enough examples have been provided to demonstrate the need for this and I would like to know from somebody on the collaboration team or main code team what is the hold up or concern in implementing this feature? It’s long overdue.

[kaem-e]

they're never going to address this are they

[arsdever]

Did no one find a workaround? It's been 6years since this issue was reported. I want to specify different clang-format executable paths based on the platform since I use the sync settings feature. And I'm not able to do it?

[nebbles]

@arsdever As mentioned above in https://github.com/microsoft/vscode/issues/5595#issuecomment-564966427, we had the same problem. Since that post (over 2 years ago), we haven't needed to change our solution of using the platform-settings extension.

We committed the clang-format binaries that we needed into the repository. Then we configured the platform-settings extension in the .vscode/settings.json:

"platformSettings.autoLoad": true,
"platformSettings.platforms": {
    "darwin": {
        "nodes": {
            "C_Cpp.clang_format_path": "${workspaceRoot}/bin/clang-format/darwin_x64/clang-format"
        }
    },
    "linux": {
        "nodes": {
            "C_Cpp.clang_format_path": "${workspaceRoot}/bin/clang-format/linux_x64/clang-format"
        }
    },
    "win32": {
        "nodes": {
            "C_Cpp.clang_format_path": "${workspaceRoot}/bin/clang-format/win32/clang-format.exe"
        }
    }
},

[arsdever]

Thanks for your quick reply @nebbles. I don't like having installed a lot of extensions (the default set for supporting c++ and cmake is quite enough for me 😄 ). I'm thinking to solve the problem by configuring the PATH variable to point to the correct place, or, maybe, having a dedicated envvar for that and using it in the settings.

It's sad to know that the thread wasn't revisited even having this many vote-ups. It would have provided a ton of flexibility, especially when you have user sync settings.

Edit

BTW I looked at the previous comments and saw your suggestion even before your respond, but anyway, thanks for pointing it out explicitly.