Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PS1 missing parenthesis around venv #24097

Closed
AddisonG opened this issue Sep 11, 2024 · 6 comments
Closed

PS1 missing parenthesis around venv #24097

AddisonG opened this issue Sep 11, 2024 · 6 comments
Assignees
Labels
area-terminal bug Issue identified by VS Code Team member as probable bug info-needed Issue requires more information from poster triage-needed Needs assignment to the proper sub-team

Comments

@AddisonG
Copy link

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

(venv) addison@home ~/tmp $:
^^^^^^ Looks good!

What I get:

venvaddison@home ~/tmp $:
^^^^ Yuck!

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:

{
	"folders": [
		{
                         # This project dir is right beside the workspace file - it has a relative path
			"path": "my-working-project"
		},
		{
                         # This project uses an absolute path - it breaks
			"path": "/Users/addison/other/my-BROKEN-project"
		},
		{
                         # This also breaks, just in case you were going to ask
			"path": "../other/my-BROKEN-project"
		},
...

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)

  • Ubuntu 24.04, Python3.13, vscode: 1.93.0, Microsoft Python Extension: v2024.14.0
  • Darwin arm64 22.6.0, vscode: 1.92.2 (Universal), Microsoft Python Extension: v2024.14.0
    • Difficult to reproduce on Mac. Definitely still happens - and seems to relate to the Python version
    • Seems to sometimes be related to the import path of the dir into the vscode project

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.
#23201

Here is a stack overflow post I made, about the same thing:
https://stackoverflow.com/questions/78961614/vscode-ps1-missing-parenthesis-around-venv

@github-actions github-actions bot added the triage-needed Needs assignment to the proper sub-team label Sep 11, 2024
@anthonykim1
Copy link

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

@anthonykim1 anthonykim1 added area-terminal bug Issue identified by VS Code Team member as probable bug and removed triage-needed Needs assignment to the proper sub-team labels Sep 16, 2024
@github-actions github-actions bot added the info-needed Issue requires more information from poster label Sep 16, 2024
@AddisonG
Copy link
Author

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 double source 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.

@Chrisguagliano
Copy link
Member

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 !

@AddisonG
Copy link
Author

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.

@anthonykim1
Copy link

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 :)

@anthonykim1 anthonykim1 reopened this Sep 24, 2024
@github-actions github-actions bot added the triage-needed Needs assignment to the proper sub-team label Sep 24, 2024
Copy link

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!

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Oct 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-terminal bug Issue identified by VS Code Team member as probable bug info-needed Issue requires more information from poster triage-needed Needs assignment to the proper sub-team
Projects
None yet
Development

No branches or pull requests

3 participants