Skip to content

Only show python status bar item when you are in a python file #10609

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

Closed
mjbvz opened this issue Mar 17, 2020 · 4 comments
Closed

Only show python status bar item when you are in a python file #10609

mjbvz opened this issue Mar 17, 2020 · 4 comments
Assignees
Labels
area-environments Features relating to handling interpreter environments feature-request Request for new features or functionality needs proposal Need to make some design decisions partner ask

Comments

@mjbvz
Copy link

mjbvz commented Mar 17, 2020

Environment data

  • VS Code version: 1.44.0-insider
  • Extension version (available under the Extensions sidebar): 2020.4.68094-dev
  • OS and version: MacOS 10.15.3
  • Python version (& distribution if applicable, e.g. Anaconda): 3.7.3
  • Type of virtual environment used (N/A | venv | virtualenv | conda | ...): NA
  • Relevant/affected Python packages and their versions: NA
  • Relevant/affected Python-related VS Code extensions and their versions: NA
  • Jedi or Language Server? (i.e. what is "python.jediEnabled" set to; more info How to update the language server to the latest stable version #3977): Language server
  • Value of the python.languageServer setting: Microsoft

Repro

  1. Open a .py file in VS Code

  2. Now open a js file (and make sure the python file is closed)

Bug

The python info still shows in the status bar:

Screen Shot 2020-03-16 at 8 36 07 PM

In general, the status bar should only show information that is relevant for working in the current file. The python version info is not helpful when are editing a JS or markdown file

Related

@mjbvz mjbvz added triage-needed Needs assignment to the proper sub-team bug Issue identified by VS Code Team member as probable bug labels Mar 17, 2020
@luabud
Copy link
Member

luabud commented Mar 17, 2020

Hi @mjbvz! I feel that this wouldn't be helpful for those who are working on web applications such as Django or Flask. If you have js file open or even html/css, it could still part of the Python application.

Even if we hide this information when other files are open, when users open the terminal the environment will still be activated in the terminal since the Python extension is activated. This could be unexpected as the environment info isn't displayed. Related to that, having the interpreter information there gives a quick an easy way to just spot if the Python extension is actually activated in that workspace.

Anyway, I'm adding a "needs decision" label so I can discuss this further with the team.

@luabud luabud added area-environments Features relating to handling interpreter environments needs decision feature-request Request for new features or functionality and removed triage-needed Needs assignment to the proper sub-team bug Issue identified by VS Code Team member as probable bug labels Mar 17, 2020
@mjbvz
Copy link
Author

mjbvz commented Mar 17, 2020

We faced the same considerations for JS/TS. We decided to only show the status item when in js/ts files. If I'm editing a python file for example, I don't care what version of TypeScript is being used for my client side code.

If the terminal is the concern, I believe python is only activated in specific terminals (such as using Python: Create terminal). You should be able to track when one of these is active. The user should also never need to care if an extension is activated or not; the extension should activate itself transparently when it needs to be activated

The status bar does not have a lot of real estate and the python status bar entry takes up a lot of space, so please be considerate of other extensions here

@luabud
Copy link
Member

luabud commented Mar 17, 2020

If the terminal is the concern, I believe python is only activated in specific terminal (such as using Python: Create terminal).

If you run the "Terminal: Create New Integrated Terminal" command (or simply click on the + button to create a new one), it will automatically activate the environment. We also had requests to activate the first open terminal as well (e.g. #5330), but it turned out to be an opt-in feature for those who would like this functionality.

The user should also never need to care if an extension is activated or not; the extension should activate itself transparently when it needs to be activated

Sorry, I don't think I quite understand that. The Python extension activates only when you open a Python file or when you run a Python command. We then display the Python version on the status bar (which is a valuable information when you're dealing with Python, as you may have tons of interpreter on your machine and usually there is the right one you want to pick for your project).
We don't want to always activate the extension just because it's installed. So if the extension did activate on a workspace, it means the user did open a Python file, or ran a command from the Python extension.

The status bar does not have a lot of real estate and the python status bar entry takes up a lot of space, so please be considerate of other extensions here.

There's always the workaround of hiding this information for those who find it useless (by right clicking on the status bar and unselecting the Python option). But we're talking about the default experience for all of our users, and for that I strongly believe this is an important information to be displayed even if you're working with other type of files (e.g. we support template debugging, and in that case the Python interpreter will display the information of which environment will be used to launch the debug session, even though you're focused on a html file).

In any case, I will discuss this further with the rest of the team, and we're also leaving here the opportunity for others to comment and upvote this issue if they agree with this request 😊

@luabud luabud added needs proposal Need to make some design decisions and removed needs decision labels Apr 22, 2020
@luabud luabud self-assigned this Aug 12, 2020
@luabud
Copy link
Member

luabud commented May 12, 2022

Closing as we now only show it for Python files and settings. Related follow up issue: #18930

@luabud luabud closed this as completed May 12, 2022
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jun 12, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-environments Features relating to handling interpreter environments feature-request Request for new features or functionality needs proposal Need to make some design decisions partner ask
Projects
None yet
Development

No branches or pull requests

2 participants