setting process.env from extensions doesn't propagate

[jacobeatsspam]

Issue Type: Bug

From an extension, setting process.env[key] = value; does not have any effect on the parent process. My guess is that this has to do with the Extension Host subprocess. Is there an api for communicating with the parent process?

VS Code version: Code 1.41.1 (26076a4, 2019-12-18T14:57:51.166Z)
OS version: Darwin x64 18.7.0

[jrieken]

setting process.env[key] = value; does not have any effect on the parent process.

Do I get that right? You set process.env.foo in the extension host process and expect it be observed in the renderer or terminal that launched the extension host process?

[jacobeatsspam]

@jrieken correct. You can reproduce this by creating a new extension with yo code and editing:

	// The command has been defined in the package.json file
	// Now provide the implementation of the command with registerCommand
	// The commandId parameter must match the command field in package.json
	let disposable = vscode.commands.registerCommand('extension.helloWorld', () => {
		// The code you place here will be executed every time your command is executed

		// Display a message box to the user
		vscode.window.showInformationMessage('Hello World!');

		process.env['AA_FOO'] = 'BAR';
		console.log(process.env);
	});

When I open the developer tools I can see that it is set within the Extension Host subprocess, however when I inspect process.env the environment is unchanged.

My original reason for looking into this was to attempt better support for tools like rbenv, goenv, tfenv, etc.

[vscodebot]

The described behavior is how it is expected to work. If you disagree, please explain what is expected and what is not in more detail. See also our issue reporting guidelines.

Happy Coding!

[jrieken]

Thanks for clarifying, however a child process cannot pass/change env variables to a parent process. afaik this limitation is universal and not just vscode

[jacobeatsspam]

@jrieken Understood, I'm fully aware of how processes are handled, and everything that is happening makes sense. That is why the initial post finishes with the question of if the parent process exposes an API or something. And I explained the environment example in the hopes that if there wasn't an API, maybe it'd inspire thought of another solution/approach I'm not considering (maybe electron exposes some rpc? i don't really mess with electron much). My apologies if my straight to the point approach came off as naive.

Edit: also apologize for this getting filed as a Bug. It's more of a Question

[jrieken]

There is API to talk back to parent because the renderer kinda protects itself. Changing env is generally tricky because how would downlevel consumer know that they have changed, e.g a child process of another child process?

My original reason for looking into this was to attempt better support for tools like rbenv, goenv, tfenv, etc.

To get back to original need. You might be better off with the task-API - it allows you to define "tasks" that run as process or via the shell and that allows to define args and env. Adding @alexr00 for more background if needed

[alexr00]

Tasks can be used to run build scripts (and other scripts and processes) and you can set up an environment for those tasks. The documentation, the api, and the example extension are all good places to start.

[jacobeatsspam]

@jrieken @alexr00 Thanks for the info and links. I definitely trolled the documentation and tried a few approaches before creating this ticket, but unfortunately none of this scratches what I'm trying to solve. If you're familiar with the various env tools (direnv, rbenv, pyenv, nodenv, goenv, tfenv, etc), they modify your environment and PATH relative to files in the directory. This in turn should have an effect on plugins like Python, Terraform, Ruby, etc, so they find the intended binary/tool. This would require updating the running parent process, or restarting it after sourcing said environment changes.

So far my work around has been to navigate to the project directory, which automatically modifies the environment, and then launching with code . to inherit it. This means that if I need to change versions or do anything that would effect this environment, I have to quit and restart the editor, and makes the File -> Open Recent navigation useless.

I was hoping to write a plugin that monitors such files for changes and then updates the primary process' environment accordingly. Approaching this from the Tasks API doesn't seem to be useful.

[jacobeatsspam]

There is API to talk back to parent because the renderer kinda protects itself.

@jrieken Could you link me to documentation of this API that you're thinking of so I could look around?

To expand a little further, without figuring out a reliable way to alter the running environment of the main process, things like Tasks automatically picking up Makefile tasks won't work as expected for users using these tools because only the terminal, and things launched from it, will trigger the altering of the user's PATH. Like I said, so far the only way I have figured out is to alter the environment and then start vscode, but this is cumbersome.

[jacobeatsspam]

@jrieken Here is another example of users impacted by this workflow. He is suggesting the ability to set load order? But my understanding is that doesn't matter because each extension runs in it's own process, or am I wrong?