You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
VS Code version: 1.18.0
Python Extension version: 0.8.0
Python 2 Version: 2.7.14
Python 3 Version: 3.6.2
OS and version: Fedora 26 x86_64
Actual behavior
The extension always starts when debugging any kind of project.
Expected behavior
The extension probably shouldn't start when debugging projects that do not contain any python code.
Steps to reproduce:
Open a non-python project with a launch.json file
Start a debugging session with F5
From what I see in package.json's activation events, it looks like it's supposed to activate on any debugging session. However I don't see the point, as it only slows down debugging other projects.
I know I can just disable the extension for non-python projects, but that activation event still seems a bit overkill. Is there a reason for not using "workspaceContains:**/*.py" (and a few others for other extensions) instead ?
The text was updated successfully, but these errors were encountered:
This was left as its possible to start debugging Python code even without having a Python file open (i.e. the activation was the debugger).
However, using "workspaceContains:**/*.py" should fix this.
Environment data
VS Code version: 1.18.0
Python Extension version: 0.8.0
Python 2 Version: 2.7.14
Python 3 Version: 3.6.2
OS and version: Fedora 26 x86_64
Actual behavior
The extension always starts when debugging any kind of project.
Expected behavior
The extension probably shouldn't start when debugging projects that do not contain any python code.
Steps to reproduce:
launch.json
fileF5
From what I see in
package.json
's activation events, it looks like it's supposed to activate on any debugging session. However I don't see the point, as it only slows down debugging other projects.I know I can just disable the extension for non-python projects, but that activation event still seems a bit overkill. Is there a reason for not using
"workspaceContains:**/*.py"
(and a few others for other extensions) instead ?The text was updated successfully, but these errors were encountered: