Vscode: Add OS-specific dependency PATHs

[theetrain]

• VSCode Version: 1.8.1

I develop on Ubuntu 16 and Windows 10 interchangeably, and my paths to Node, PHP, and others differ on each platform. I'd like to add OS-specific paths in my settings.json since I synchronise my user settings across each platform via Dropbox.

Something like this would be useful:

"paths": {
    "linux": [],
    "osx": [],
    "windows": [
        "C:/Program Files (x86)/PHP/php-5.4/"
    ]
}

[ghost]

Definitely, I'd like to be able to do this so I can tailor a working, cross-platform setup for a repo

[nijikokun]

I also agree this should be a configurable setting, not always are the binaries I would like to develop with are on my PATH

[ghost]

These values will be addable to the user settings or the workspace settings? I'd rather have the latter.

[egamma]

CC @weinand @bpasero

[fredrikaverpil]

It would be very useful to be able to specify the OS-specific value of any user setting and any workspace settings, including extensions settings.

I've requested the very same thing for the PythonVSCode project.

[weinand]

For launch.json we already support OS-specific configurations. Any configuration can be nested inside an OS qualifier, e.g. "linux": { "foo": "bar" }.

[seanmars]

Hope the workspace setting can add specific os block for os, like:

{
  windows: {
    ...
  },
  osx: {
    ...
  }
}

[fredrikaverpil]

There hasn't been much activity on this for a while. Has there been any progress further discussion on...

• being able to set variables in settings and workspace settings? (this issue and #18709)
• being able to use such variables in settings and workspace settings? (#2809)

[fredrikaverpil]

ping @sandy081 - would it be possible to evaluate a priority bump (out of backlog) for creating/using variables in settings and workspace settings?

This would be so good for cross-platform development where paths differ on different machines/platforms.

[sandy081]

@fredrikaverpil No plans at present. Will let you know once we planned.

[repentsinner]

It would be much appreciated to support something like the following in a ${workspaceRoot}/.vscode/settings.json file. Currently it's not clear how to share workspace settings via source control on projects that may be contributed to from multiple platforms.

{
   "windows": {
        "python.pythonPath": "${workspaceRoot}\\.venv\\Scripts\\python.exe"
    },
    "osx": {
        "python.pythonPath": "${workspaceRoot}/.venv/bin/python"
    },
    "python.formatting.provider": "yapf",
    "other.shared.settings":"go.here"
}

Thanks for considering!

[dipnlik]

Related: #8962

[ddotlic]

@sandy081 Hey, sorry to bump this but I was thinking: the people using VS Code across at least two platforms are likely your most valuable users as they can uncover xplat issues and are likely very passionate so catering to them should be _tiny bit_ higher priority then the rest, no? 😉

As for me, I use VS Code on a macOS and Windows and having per-OS settings would be very welcome. Thinking about a possible design of this feature (not looking into the source though) does not seem like too difficult a thing to do.

Please consider putting this into one of the next few iterations. Thanks!

[sandy081]

@ddotlic Will bring it up in our next planning meeting.

[ddotlic]

@sandy081 Great, thanks for everything.

[WSLUser]

This would be useful for WSL since typically you'll be using tools from both Windows and Linux and you may not want to use wslpath or wslenv for whatever reason or those functionalities may not even be known to a developer so having this feature would make it more x-plat/WSL friendly.

[brunoabinader]

This feature is highly desirable - VS Code team please implement it!

[fredrikaverpil]

@sandy081 it was mentioned before, but when you'll bring this up internally, please also keep this one in mind as it's related: https://github.com/Microsoft/vscode/issues/2809

[sandy081]

5595 is also same request. Hence closing this and track it in there.

Duplicate of #5595

[vscodebot[bot]]

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!