Skip to content

Feature request: option to re-enable traditional virtual environment activation for terminal identifier #22611

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

Open
Nevrai opened this issue Dec 8, 2023 · 4 comments
Labels
area-environments Features relating to handling interpreter environments community ask Feature request that the community expressed interest in feature-request Request for new features or functionality needs proposal Need to make some design decisions

Comments

@Nevrai
Copy link

Nevrai commented Dec 8, 2023

Issue Description

Recent updates to the Visual Studio Code Python extension (25 October) have changed how the activation of virtual environments is handled in the terminal. While the environments are indeed activated, the traditional visual indicator (e.g., (.venv)) is no longer displayed in the terminal prompt. This change, whilst addressing certain technical limitations, has impacted the user experience by removing a clear and immediate visual confirmation of the active environment.

Suggested feature

I propose introducing a setting in the Python extension that allows user to choose between the new implicit activation method, which uses the new VSCode API, and the traditional method of automatically running activate or .\venv-name\Scripts\Activate.ps1. While there are benefits to using this new VSCode API method, I personally much prefer seeing the name of the virtual environment in the terminal, as it provides a constant confirmation that your venv is activated and when it’s not. It also makes it much easier to work on different projects with different virtual environments simultaneously.

An option in the Python extension settings to return to the old activation method, if feasible, would be a very welcome addition, as it would restore the visual venv indicator in the terminal. Alternatively, if it would be possible to implement a different type of visual indicator displaying the name of the currently activated vend in the terminal, that would also be fantastic.

Rationale

The primary reason for this request is the clarity and assurance that comes with the visual indicator. Many developers, including myself, find it incredibly useful to have immediate visual feedback confirming which environment is active or whether one is active in the first place, especially when working with multiple projects or environments.

Additional context

From my understanding, based on the discussion in issue #11039 on the Python extension’s GitHub repository, this change was made to overcome certain technical challenges. Whilst the rationale is understandable, providing users with the flexibility to choose their preferred method could greatly enhance the user experience without compromising the extension’s functionality, provided this is a feasible and possible feature to implement to the extension.

Thank you for considering this feature request. The Python extension is a vital tool for every Python developer using VSCode, and enhancements like this could significantly improve the development workflow.

@Nevrai Nevrai added the feature-request Request for new features or functionality label Dec 8, 2023
@github-actions github-actions bot added the triage-needed Needs assignment to the proper sub-team label Dec 8, 2023
@eleanorjboyd eleanorjboyd assigned karrtikr and unassigned karrtikr Dec 11, 2023
@eleanorjboyd eleanorjboyd added the needs community feedback Awaiting community feedback label Dec 11, 2023
Copy link

Thanks for the feature request! We are going to give the community 60 days from when this issue was created to provide 7 👍 upvotes on the opening comment to gauge general interest in this idea. If there's enough upvotes then we will consider this feature request in our future planning. If there's unfortunately not enough upvotes then we will close this issue.

@eleanorjboyd eleanorjboyd added area-environments Features relating to handling interpreter environments and removed triage-needed Needs assignment to the proper sub-team labels Dec 11, 2023
@ClaasRostock
Copy link

From my end, it doesn't necessarily need to be the old activation method offered. Key is the visual indicator, e.g. (.venv). , which indeed I also miss.

@brettcannon
Copy link
Member

Thank you to everyone who upvoted this issue! Since the community showed interest in this feature request we will leave this issue open as something to consider implementing at some point in the future.

We do encourage people to continue 👍 the first/opening comment as it helps us prioritize our work based on what the community seems to want the most.

@brettcannon brettcannon added needs proposal Need to make some design decisions community ask Feature request that the community expressed interest in and removed needs community feedback Awaiting community feedback labels Feb 8, 2024
@suuppl
Copy link

suuppl commented Jul 17, 2024

For powershell on windows, adding this to settings.json works as a workaround:
(assuming the venv dir is in the opened directory and called .venv, this is the default when creating a venv with Python: Create Environment... -> Venv)

"terminal.integrated.profiles.windows": {
        "PowerShell": {
          "source": "PowerShell",
          "icon": "terminal-powershell",
          "args": ["-NoExit", "-Command", "$venvPath = \".venv\\Scripts\\Activate.ps1\"; if (Test-Path $venvPath) {& $venvPath}"]
        },
        "Command Prompt": {
          "path": [
            "${env:windir}\\Sysnative\\cmd.exe",
            "${env:windir}\\System32\\cmd.exe"
          ],
          "args": [],
          "icon": "terminal-cmd"
        },
        "Git Bash": {
          "source": "Git Bash"
        }
      },

This is the default setting, except with added args for the profile "PowerShell".

With these args, a command is passed to the new powershell process.
The command checks if .venv\\Scripts\\Activate.ps1 exists and executes it if it does. Adjust the path as needed and note the escaped quotes.
-NoExit is needed so the new terminal doesn't just immediately exit after running the command.

Hope that helps 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-environments Features relating to handling interpreter environments community ask Feature request that the community expressed interest in feature-request Request for new features or functionality needs proposal Need to make some design decisions
Projects
None yet
Development

No branches or pull requests

6 participants