Add several basic predefined variables for use in launch.json - e.g. ${uid}, ${gid}, ${user}, ${home}

[Nowaker]

Please expose several basic predefined variables for use in launch.json like ${uid}, ${gid}, ${user}, ${home} (and potentially in settings.json too, as per #2809).

Example use cases:

1. Extremely useful for multi-user environments to avoid port or path conflicts. (See YAML below)
2. Generally similar use cases to Support variables when resolving values in settings #2809 where one needs to specify paths to SDKs, GOPATHs and alike.

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "perl",
      "request": "launch",
      "name": "Perl-Debug",
      "console": "remote",
      "port": "${uid}",  // <---- HERE!
      "root": "${workspaceFolder}/.vscode/root",
      "program": "${workspaceFolder}/${relativeFile}",
      "stopOnEntry": false,
      "reloadModules": false,
      "sessions": "watch",
    }
  ]
}

[weinand]

USER and HOME are already available as environment variables: ${env:HOME} and ${env:USER} and you can easily make others available by defining them as environment variables in your shell profile.
If this doesn't work for you, write an extension that registers commands like "uid" or "gid". You can access these via the command syntax: ${command:uid} or ${command:gid}

We are not planning to introduce arbitrary variables that are already available by other means.

[ssbarnea]

HOME is already supported, being named userHome based on https://code.visualstudio.com/docs/editor/variables-reference so we can remove it from the title/description.

Meanwhile there are 3 other very important variables that we need:

• platform to resolve as windows, linux or macos.
• arch to resolve as x64 or arm64
• hostname to report the current hostname

These 3 variables are essential for allowing us to use configure paths to tools or virtualenvs that are not clashing when a workspace is mounted on multiple systems.

To give a clear explanation, python virtualenvs are not portable and this means that a folder like .venv would be usable only from the machine on which it was created.

My main development box is a MacOS host where I also use Parallels to run a Windows Vm and a Linux VM, both of them have my code mounted on them, so I do not need to sync any code change. And here is where the joy starts, as as soon I create a python .venv inside the project, vscode detects it and starts using it on all platforms, basically at any point in time only one is working and the other ones do not.

I got the same problem with tox but for tox there is a workaround as you can configure it to include the platform name inside its virtualenv, so you can make it work cross-platform. Still, with vscode itself, there is no way to configure that yet:

"python.defaultInterpreterPath": "${workspaceFolder}/venv-${platform}/bin/python"

If we would have platform, arch or at least hostname, we could ensure that these are isolated and not clashing when using file mounts.

And yes, I do also run vscode under each of these VMs because I happen to code extensions for vscode, so I need to check how it behaves on each.

Implementing platform reporting with node is very simple, process.platform does a decent job.

Can a core engineer ack if a pull-request to add this would be accepted?

[weinand]

@ssbarnea did you try to use an environment variable that is defined outside of VS Code? You can easily access that as `${env:variable}´.

[ssbarnea]

While using env trick is awesome, it cannot work for this use-case because someone decided to use COMPUTERNAME instead of HOSTNAME on Windows, despite all other operating system I know expose HOSTNAME. So not portable.

[weinand]

@ssbarnea I was actually suggesting to introduce a new env variable and assign it to different values on the different platforms.