microsoft / vscode-python

Python extension for Visual Studio Code
https://aka.ms/pvsc-marketplace
MIT License
4.33k stars 1.19k forks source link

PS1 missing parenthesis around `venv` #24097

Closed AddisonG closed 2 weeks ago

AddisonG commented 1 month ago

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)

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

anthonykim1 commented 1 month 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

AddisonG commented 1 month ago

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 commented 1 month 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

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 commented 1 month ago

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 commented 1 month ago

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

github-actions[bot] commented 2 weeks ago

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!