Skip to content

Consider activating the environment without environment variables #241

Open
@Tyriar

Description

@Tyriar

Testing #226

Related #240

The way I was envisioning this working was something like this:

  1. Create a symlink in the user data dir for each shell that points at the vscode-python directory
  • Every update, this symlink is replaced
  • We would own this file and don't need to ask the user to create it
  1. Upon opting in to shellStartup, either via manual or as the default UX with a dialog (Rethink modal dialog #232). Add code to each shell script that sources symlink
  2. Upon opening a window (maybe other events?), verify the symlinks

Using this approach, the shell scripts can be smarter than just a simple source script and we don't need to pollute the environment (#240). They can also be as verbose as we want it to be and we can keep the calling of the script quite concise since things like exiting when TERM_PROGRAM!=vscode can be inside this script that is a living file and can be changes as we improve the activation logic (#234).

Other thoughts:

  • To prevent double activation, you could add an environment variable that declares it was activated. Maybe $SHLVL is useful here?
  • No environment changes means no more ⚠ icons related to python environments
  • We could make it be safe to assume this would only activate when opening a terminal inside VS Code and not sub-shells, so the cwd can be used as the root of the repo to activate
  • The change in scripts can be very concise and clear, like a line with a comment followed by a line to source the file, since we can and want to move conditions into the script.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions