Add ability to set environment variables when creating a Debug Adapter

[glennsarti]

I currently have Debug Adapter implemented in Ruby language. Ruby has some configuration which is only possible to set via environment variables, such as GEM_HOME.

To get around this I have to write a large Typescript file which spawns my real Debug Adapter in ruby, and then just proxies stdin/stdout between the two. This is awkward, prone to error and quite limited as the debug adapters don't have access to the vscode configuration classes (separate process).

Ideally I should be able to set path, arguments and environment for debug adapter runtime.

Proposed changes

Currently the Debug Adpater runtime configuration only offers runtime path, and arguments, as can been see in;

https://github.com/Microsoft/vscode/blob/master/src/vs/workbench/parts/debug/node/debugAdapter.ts#L299

Note that we cannot configure the spawn options, which is where the environment variables would go. Also other IO options but I'm not as interested in them.

Given that the DebugAdapterExecutable class is currently in a proposed state, I would like to add additional functionality to do this now.

Proposed changes (pseudo code style!)

	/**
	 * Represents a debug adapter executable and optional arguments passed to it.
	 */
	export class DebugAdapterExecutable {
		/**
		 * The command path of the debug adapter executable.
		 * A command must be either an absolute path or the name of an executable looked up via the PATH environment variable.
		 * The special value 'node' will be mapped to VS Code's built-in node runtime.
		 */
		readonly command: string;

		/**
		 * Optional arguments passed to the debug adapter executable.
		 */
		readonly args: string[];

		/**
		 * Optional environment variables set for the debug adapter executable.
		 */
		readonly env: object;   <---- Map<string, string> or something

		/**
		 * Create a new debug adapter specification.
		 */
		constructor(command: string, args?: string[], env?: Object);  <---- Map<string, string> or something
	}

And spawn option change

let spawn_options: cp.SpawnOptions = {};
spawn_options.env = mergeEnvironmentVariables(process.env, this.adapterExecutable.command.env);
this.serverProcess = cp.spawn(this.adapterExecutable.command, this.adapterExecutable.args, spawn_options);

Where mergeEnvironmentVariables would take a set of existing env vars (process.env) and then merge the new set of env vars into it.

Obviously there will be some other code changes to actually read in the env vars from the extension package.json. Or perhaps only offer this IF implementing via debugAdapterExecutable and not via package.json?

https://github.com/Microsoft/vscode/blob/e5c3c0f37e993de6a0f8fe6d2ce6596d4e5745ae/src/vs/workbench/parts/debug/common/debug.ts#L424-L427

Other options

Saying that environment should be configured BEFORE you start VSCode isn't always feasible or responsible. That means I can't use different runtimes depending on user settings.

Configuring the runtime environment BEFORE using code for MY debug adapter may break OTHER extensions unexpectedly. Given we're spawning a new process, it is feasible to have the VScode environment setup for Editing and the debug adapter setup for debugging.

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• It is not possible to see any error output from crashed debug adapter extension (#40198)
• How vscode knows about the server port no of debug adapter when it itself starts debug adapter ? (#54173)

[glennsarti]

Note that this is different to setting the environment of the debugee. This is about spawning the Debug Adapter itself, which can then spawn debugee processes.

[glennsarti]

Neither of the issues mentioned above are duplicates. I searched the current and closed issues and found nothing about this. Only about passing env vars into the debugee, not for the DA itself.

[glennsarti]

@weinand @isidorn Given this is for a proposed API change, would I be able to raise a PR myself for it?

[weinand]

@glennsarti thanks for the offer, but I'm currently working on this API anyways. So I will definitely consider this feature.