Closed AddisonG closed 2 weeks ago
Hi @AddisonG Thanks for filing this issue. Can you try adding:
"python.experiments.optOutFrom": ["pythonTerminalEnvVarActivation"],
to your settings.json and see if that works? Thanks
Hey @anthonykim1,
Yeah, that absolutely does work (after adding the setting and reloading vscode).
It works because when I open a new terminal, it actually runs a real command, as if I was running it manually:
source /Users/addison/path/to/my/project/venv/bin/activate
addison@work ~/tmp $ source /Users/addison/path/to/my/project/venv/bin/activate
(venv) addison@work ~/tmp $
Note that it looks like the source command was run twice, but that's almost certainly a result of vscode pasting the command in before the terminal rendered the
PS1
. Please ignore the doublesource
command
So in this regard, it is fully functional.
Interestingly, this actually reminds me of another bug, which is that I'm finally able to run the deactivate
command here, to exit my venv.
Normally, I'm unable to do that, when I'm opted into the env-var-activation, because that janky auto-env-var thingo doesn't actually seem to run the activate
script, so you can't deactivate it. Annoying if you decide you want a "clean" terminal.
Hi @AddisonG Thanks for filing this issue. Can you try adding:
"python.experiments.optOutFrom": ["pythonTerminalEnvVarActivation"],
to your settings.json and see if that works? Thanks
This fixed it for me on Windows and WSL. I think I prefer the confirmation that the venv was activated upon terminal startup as well. Going to keep it this way. Thanks @anthonykim1 !
Woah there! This is not completed yet, unless I'm mistaken.
It's still a problem for everyone who doesn't read this exact GitHub issue.
Putting in a line to your settings to opt-out of experimental features is a workaround.
I really appreciate the help, and the workaround, but this is definitely still broken.
Hi @AddisonG I understand, that is a fair point!
The eventual plan to get rid of pythonTerminalEnvVarActivation, for better experience but we can totally have this upvote so people can surely reference the workaround and the dev team can be kept on reminded that this issue exist :)
Because we have not heard back with the information we requested, we are closing this issue for now. If you are able to provide the info later on, then we will be happy to re-open this issue to pick up where we left off.
Happy Coding!
Summary
I have several fully functioning projects, each with their own venv.
Randomly, and unpredictably, they will sometimes become afflicted by a curse which causes the
PS1
bash prompt to display wrong:What it should be
What I get:
Description
This is a pain to reproduce on Mac, and I have not managed to reliably get a minimal reproduction case, but I have a repro on Ubuntu (documented here).
It seems that the issue is caused (maybe?) on MacOS by just being
/Users/addison/work/allprojects.code-workspace
:I'm pretty sure that just moving the project into a different dir works, except that you have to re-generate the venv, as it contains absolute paths.
I can confirm that this is unrelated, to the
venv/bin/activate
being different between "broken" folders in a workspace. These files are identical in every way (except for the line:VIRTUAL_ENV=/different/path/for/each/project
) when comparing a broken folder which exhibits this behaviour (venvusername
), and a functioning folder which does not ((venv) username
).Environment and Versions
This happens on Mac and Linux (and probably also Windows, but unconfirmed)
Python 3.9, 3.10 and 3.13 - probably all versions?
Links
This is the PR I believe caused this issue, or may be related to it in some capacity. https://github.com/microsoft/vscode-python/pull/23201
Here is a stack overflow post I made, about the same thing: https://stackoverflow.com/questions/78961614/vscode-ps1-missing-parenthesis-around-venv