You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The way I was envisioning this working was something like this:
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
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
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.
Testing #226
Related #240
The way I was envisioning this working was something like this:
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:
$SHLVLis useful here?