If I have Python-related files in my workspace, automatically activate the extension

[DonJayamanne]

Goal - Lets not wait for the user to open a python file to activate the extension

If the user has some of the following files we could probably activate the extension without having to wait for the user to open a python file:

• pip env files
• poetry files
• setup.py
• setup.cfg?
• tox.ini
• pyproject.toml
• pytest.ini
• requirements.txt
• test_requirements.txt
• .pylintrc
• .flake8
• __init__.py
• manage.py
• src/__init__.py
• tests/__init__.py
• meta.yml
• environment.yml
• anaconda-project.yml
• .pep8
• .pycodestyle

[znd4]

I know you included etc., but I'd like to explicitly call out meta.yml, environment.yml, and maybe even anaconda-project.yml. :)

[wis]

also .pep8 and I think .pycodestyle

[DonJayamanne]

@luabud we have an external PR for this issue.
FYI, this was meant to be an experiment, hence the label.
We might also want to list down each file that we want to support/look for.

[karthiknadig]

@DonJayamanne this is a change to package.json. Is there a way to add this to experiment?

[DonJayamanne]

Sorry, I missed that question.
I can see only one way of doing this.
When extension loads, we modify package.json file, then next time they load extension package.json file will contain the required changes and things will work as expected.

I.e. extension will need to modify package.json during runtime, instead of shipping it.

We might need to change how this experiment works, else we'll get telemetry for users who open VSC once and we'll (via telemetry) get notified they are in the experiment, when in fact they aren't (not until they re-load VS Code).

[sanmai-NL]

If you do this, please be very selective about which files to trigger on. setup.cfg or requirements.txt are hardly limited to Python solutions. I think a better approach would be to immediately activate those extensions that were enabled in the workspace, for cases involving a workspace.

[luabud]

@sanmai-NL if the Python extension is disabled for a workspace, it won't be activated at all at any point. This simply talks about when the Python extension is enabled globally, but users would like to have it activated automatically, without having to open a Python file or triggering a command.

That said, we should definitely be mindful in which files to trigger it on. I've only ever used requirements.txt for Python projects, so I'd love to learn more about which other contexts it's commonly used 😊

From the list of files mentioned, is there anything else you think would not be mostly related to Python?

[sanmai-NL]

I say not being enabled or not being recommended rather than being disabled.

[BrandonLWhite]

I'd be thrilled if we could just get going with pyproject.toml in the project root and defer on all the others.

[ericsnowcurrently]

@luabud, @brettcannon, @karthiknadig, any thoughts on this for the short-term? @BrandonLWhite, has a PR up for just "pyproject.toml". If we're doing it for one we should at least do it for the following:

• setup.py (and maybe setup.cfg)
• pyproject.toml
• maybe *.py (only top-level)

We could also do it for **/*.py (and .pyi), but that might be too much (though */*.py might be okay).

[sanmai-NL]

@ericsnowcurrently: #4765 (comment)

[brettcannon]

@ericsnowcurrently we can't do it on just .py files as too many projects use Python scripts for basic things and yet the frequency of editing those files is so low that activation would be annoying. We really can only do this with files that we know are common to Python projects, not just projects that use Python.

As for whether we are ready to move forward with this, that's a call for @luabud . But starting with pyproject.toml is probably the safest file since it is explicitly for Python projects alone.

[ericsnowcurrently]

Agreed, though I'd add setup.py at the same time. Between the two files we would get pretty good coverage. Let's start with that. We can tackle other stuff (including setup.cfg) later.

[iutlu]

Hello, I was wondering if this new behavior was going to be controllable by a setting. It's quite desirable on its own, but as a workaround for microsoft/vscode-remote-release#1760, I've been trying to control when the Python extension gets loaded by closing any active Python files before I reload the VSCode window (for the cases when I need to reload VSCode)

[brettcannon]

One thing to be aware of is we used to get complaints about being overly liberal with launching the extension by folks who happen to have Python scripts in their e.g. C++ code base who do nothing more than generate test data by running Python, and so they only edit Python code every couple of months and not every time they open a workspace.

Without discussing it with the team 😉 , my guess is we can probably consider files that very clearly delineate that a project is primarily Python-based (e.g. pyproject.toml), but we can't do it for just any file that someone using Python for any reason may have (e.g. configuration files for linters which you might have set up for that one Python file you have).

So I think that would suggest we could consider:

• Pipfile
• setup.py
• requirements.txt
• manage.py for Django
• environment.yml for Anaconda (maybe; that file is not exclusive to Python, e.g. R projects use the same file for Anaconda so this might not work out)

We don't need setup.cfg as that's covered by setup.py and pyproject.toml (otherwise that file is useless). pyproject.toml also takes care of Poetry. And everything else doesn't necessarily suggest the code base is oriented towards Python (e.g. SConstruct has the issue of being used by projects that are not necessarily Python-focused, and using Pylint just means you have some Python code).

[znd4]

I like that thought process :)

The bit about R Anaconda projects is a good one, and it'll apply to anaconda-project.yaml as well. (also, I'll retract my meta.yaml recommendation, because that name is way too generic)

I've seen a few data science projects just using Dockerfiles for dependency management, but the line probably has to be drawn somewhere before "parsing build scripts". Besides, those projects should at least be using requirements.txt most of the time.

[Soneji]

This sounds amazing! Thank you for all your hard work folks :)

[akospasztor]

Sounds great! I would also highly support the consideration of requirements.txt.

[brettcannon]

@luabud what do you think about my proposed list of files for triggering?

[luabud]

I like it, I'd just add app.py for Flask too if you think that'd be ok!

[brettcannon]

@luabud WFM!

Would anyone hear like to open a pull request to add the following files as triggers for the extension?

1. Pipfile
2. setup.py
3. requirements.txt
4. manage.py
5. app.py

[Soneji]

Yup :)

[brettcannon]

Thanks to @Soneji for the PR and everyone else in constructively participating in the discussion! This will be out in our March release.

[dataders]

this is amazing. it was def my biggest UX painpoint of the vscode-python extension (and maybe of all of VSCode?!). This particularly will help users of dbt!

[lsorber]

@Soneji Could you also add a trigger for environment.yml for conda users? 🙏

[Soneji]

hey @lsorber

I can send another PR (and so could you! 😉 ) but it's up to the team that maintains the project (@brettcannon , @luabud , etc.) whether they approve of it and ultimately whether it gets merged.

[Soneji]

Also, if we're increasing the list of files, we should definitely add the poetry files too (from the first comment), like pyproject.toml

[brettcannon]

@lsorber environment.yml is a little tricky because it's used by conda in all languages they support, e.g. R. So we would over-trigger in that instance and we have already received a lot of complaints in the past about launching when we weren't wanted. And because this is declarative in package.json we can't programmatically say "trigger for environment.yml if it lists a Python version" or something.

@Soneji we have actually been triggering for pyproject.toml for at least 7 months now, so Poetry users are all good 😄

[lsorber]

@brettcannon thanks for clarifying, that makes sense. Would it be possible to trigger activation based on their being a virtual/conda environment associated with the workspace? That should have pretty high recall and precision I expect.

[brettcannon]

@lsorber only if there's a way to statically list a file to trigger against. All the details of what we can trigger on can be found at https://code.visualstudio.com/api/references/activation-events. We purposefully don't blindly trigger due to how big/heavy the extension is.

[lsorber]

Right, but VS Code knows whether there's a Python environment associated with the workspace, so that seems like it would be a perfect trigger, or not?

[benlindsay]

@lsorber I like that idea if it's possible. I think all my python projects have python.pythonPath set in the workspace's settings.json file

[brettcannon]

@lsorber VS Code only "knows" that there's a Python environment because our extension makes that true. Technically VS Code itself couldn't care less about any of this; all it cares about is knowing when to launch our extension. We then bring in the concept of a Python environment after we start up. So this issue is specifically about when to launch our extension which itself brings in the concept of Python environments.

[lsorber]

@brettcannon I see, then how about a minimal startup to check whether there's a Python environment associated with the workspace and if not (and nothing else would trigger the extension) immediately shut down again?

[brettcannon]

@lsorber that is still a very expensive thing to do (and especially for conda).

[Soneji]

Maybe this could be taken to the vscode repo itself and see if they can add another type of activation event? Is there any sort of (not very intensive) activation event that could work for conda, and could even be useful for other developers?

[lsorber]

@brettcannon why would that be expensive? I'm referring to simply checking whether the user associated a Python environment with the workspace in their workspace settings.json.

Making the presence of a workspace-specific setting a new type of trigger sounds like it could be a solution (based on my limited understanding of VS Code).

[brettcannon]

why would that be expensive? I'm referring to simply checking whether the user associated a Python environment with the workspace in their workspace settings.json.

We would still have to launch the extension to detect this. Plus not every user who sets up a Python environment wants to load the extension every time (e.g. C/C++ users who have some Python code to gather test data). The existence of settings is not enough information to infer that activation of the extension is desirable in all cases. Hence why we have only trigger automatic loading on project-level files instead of any Python file existing.

Now if you're proposing a hypothetical check for a setting, then that's different, but not at all under our control as that would have to come from VS Code.

Otherwise you can open a feature request at https://github.com/microsoft/vscode-python/discussions/categories/ideas and see if enough people can convince us to ignore non-Python conda users and thus trigger on environment.yml (or you find some other file we can use to trigger on).