Do not wait for shell environment resolution before opening window

[joaomoreno]

Details: #106537 (comment)

Today: The workbench depends on user env to be resolved. Resolving user env envolves spawning a shell and executing the user's init scripts. This can take long.

Ideally: The user env is only required for specific features: opening terminals, spawning tasks, spawning extension host. Until it's resolved, many other features should actually work, ie explorer, editor, etc.

Related:

• Support per-window variable environments #15452
• Preserve per-window environment variables between workspace changes #108571
• Correctly inherit/don't inherit the shell environment #55194
• Path issues with -i #30847

Adoption

I made a pass over usages of process environment by looking at:

• direct use of process.env
• usages of IProcessEnvironment
• clients of vs/base/parts/ipc/node/ipc.cp that spawn child processes

Assigning people based on areas and usages. Feel free to remove yourself and your items when this change needs no adoption in your area.

• Terminal @Tyriar @meganrogge

  • vs/base/node/shell.ts @TylerLeonhardt

• Debug @weinand

  • vs/workbench/contrib/debug/browser/rawDebugSession.ts
  • vs/workbench/contrib/debug/node/debugAdapter.ts (only runs in EH -> nothing to do)

• Tasks @alexr00

  • vs/workbench/contrib/tasks/browser/terminalTaskSystem.ts
  • vs/workbench/services/configurationResolver/electron-sandbox/configurationResolverService.ts

• Proxy @chrmarti

• vs/platform/request/node/proxy.ts

• vs/workbench/services/extensions/node/proxyResolver.ts

Child Processes

• search @roblourens
• telemetry @sbatten

[bpasero]

After discussion with @joaomoreno we think this could work:

• we stop replacing process.env in the main and renderer processes, but instead keep it as is
• we introduce a new service IProcessEnvService that has a single method getProcessEnv(): Promise<typeof process.env>

Depending the platform, the implementation will talk to the electron-main side and ask for a merged flat view on the process environment to use:

• if the window was started from a shell (CLI) it will be the snapshot of the shell environment
  • a window will preserve this environment even when it changes its opened folder to fix Preserve per-window environment variables between workspace changes #108571
• if the window was started from the UI it will be the base renderer process.env overwritten with a shell environment which can come from one of two sources:
  • if main was started from a shell, it's that initial environment
  • if main was started from the UI, we probe the user's shell for an environment by spawning process.env.SHELL (this is the
    only reason why getProcessEnv() needs to return a promise)

Adoption needs to take place anywhere we want this merged flat view of the environment, e.g. when we spawn the extension host but also in other places. The challenge is that the environment will be a Promise and as such, previous sync code that used process.env will have to be async going forward.

[segevfiner]

If the first launch of VS Code started from CLI, under let's say some Python virtualenv, then any new window created not from CLI will have that virtualenv applied. That's unlike the case when the first launch of VS Code was from UI, where it would just have the shell environment.

What I'm trying to say is that anything that depends on whatever the first launch happened to be is confusing. It might make more sense for it to only depend on the way the current launch happened, independent of whatever the first launch happened to be. But that's just my two cents, there may be a reason for it that I'm not seeing.

Or maybe that first launch thing is really for when you launch a new VS Code window from another VS Code window, rather then the OS GUI. Maybe it would make more sense to inherit the environment of that window then, instead of the environment of the first launch.

Any work on improving the environment variables situation is more than welcome anyhow.

[bpasero]

@segevfiner that could be seen as breaking behaviour though, no? I wonder if we could have a setting that enforces that every window that opens after the first one uses the shell environment and does not inherit the first window environment if that was launched from the terminal.

Nevertheless, that still might need careful explanation as to what happens when you change the folder from within the window. Some users might expect the setting to apply there too and some maybe not.