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
{{ message }}
Repository navigation
Python extension should activate on onDebugInitialConfigurations聽#9557
Have python extension installed, workspace without a launch.json.
Do not open a python file
Press "Open launch.json" in the Debug viewlet
Python options are not presented 馃悰
The issue for this is because Python extension did not get activated since no python file got opened.
I suggest that python extension gets activated also for onDebugInitialConfigurations event. This event is fired when the launch.json is about to get populated for the first time.
When I open a Dart project and hit F5 - if I have no .dart file open, I am shown a quick-pick asking me to pick between Dart and NodeJS. If Python did this what's described above, I think it would also show up (as described by Don Jayamanne (@DonJayamanne) above).
This feels like bad UX IMO, causing debuggers for unrelated projects to show up when a user hits F5 just because there was no open file.
Yes, python would also show up. No file is open so we can not make any distincutions based on the language / active file.
There is no better way to infer what is the proper debugger to use. If you have do let us know.
Bottom line: python should still get activated on this event, the event Danny Tuppeny (@DanTup) is describing is a corner case and python should be in the same spot as the js debuggers.
Thank you for creating this issue and for proposing a solution 馃帀
I marked it as an enhancement and as "needs decision" so I can talk about this with the team 馃槉
I think it's more than that. It's pretty common to open a project and (with no files open) just hit F5. The more languages that do this, the more options the user has to read through to figure out what they need to select 馃槥
It also means that the extension will almost always be activated (anytime someone wants to debug any type of project your extension will now be activated). The C# extension does this and I'm frequently seeing it start downloading SDK/dependencies when I'm starting to debug a Dart project.
I appreciate this is the wrong issue tracker for it, but I think VS Code really needs better APIs here. In addition to the bad UX, there's a perf implication - the more languages that subscribe to this, the slower pressing F5 will be as a bunch of extensions all start running activating code (and potentially spawning language servers, etc).
I understand the concern. FWIW we're also looking into how the Python extension can be
activated faster by e.g. postponing some functionalities until they're actually needed. In this case, we wouldn't start downloading and/or executing any tools until a Python file is actually open. Then activating the extension to get the debug configuration options wouldn't be so heavy.
It's also worth mentioning that extensions can be disabled per workspace, so there's also the option to enable only the ones that are actually intended to be used on a workspace. But I also understand that this is still a problem on multi-language projects, and that not everyone is aware of this feature.
I believe we are in a position to do this now.
If I'm not mistaken the extension loads within <1 second or perhaps <less (on my mac it takes 230ms).
The slow part in the extension is when users install extension for the first time or update it, at that point the language server gets download and blocks activation of the extension (as you have identified).
This was a deliberate decision, back then resolving this was seen as an unnecessary premature optimization. Its worked for us all these months, year, hence there was no need to optimize.
However, in light of this new requirement I believe we can make that change now - maybe.
Though we'd get prompts such as Did you know you can change the interpreter, etc...
Danny Tuppeny (@DanTup) please create an issue in vscode and we can continue the discussion there.
Also this event will only be fired the very first time the launch.json is getting created. It will not be fired every time a user wants to debug.
Hi Isidor Nikolic (@isidorn) im trying to test the solution. In the step 3, the "Open launch.json" in the Debug view is outdated, now we have "create a launch.json file". But if you don't have the python extension activated then you are not be able to create a launch file for python files for initial configuration.
Can you please explain how can i test that adding onDebugInitialConfigurations activation event will work?
Activity
DonJayamanne commentedon Jan 13, 2020
DanTup commentedon Jan 13, 2020
I don't know if it's changed, but I had a niggle with
onDebugInitialConfigurationsmentioned here:microsoft/vscode-node-debug#170
When I open a Dart project and hit F5 - if I have no
.dartfile open, I am shown a quick-pick asking me to pick between Dart and NodeJS. If Python did this what's described above, I think it would also show up (as described by Don Jayamanne (@DonJayamanne) above).This feels like bad UX IMO, causing debuggers for unrelated projects to show up when a user hits F5 just because there was no open file.
isidorn commentedon Jan 13, 2020
Yes, python would also show up. No file is open so we can not make any distincutions based on the language / active file.
There is no better way to infer what is the proper debugger to use. If you have do let us know.
Bottom line: python should still get activated on this event, the event Danny Tuppeny (@DanTup) is describing is a corner case and python should be in the same spot as the js debuggers.
luabud commentedon Jan 13, 2020
Thank you for creating this issue and for proposing a solution 馃帀
I marked it as an enhancement and as "needs decision" so I can talk about this with the team 馃槉
DanTup commentedon Jan 13, 2020
I think it's more than that. It's pretty common to open a project and (with no files open) just hit
F5. The more languages that do this, the more options the user has to read through to figure out what they need to select 馃槥It also means that the extension will almost always be activated (anytime someone wants to debug any type of project your extension will now be activated). The C# extension does this and I'm frequently seeing it start downloading SDK/dependencies when I'm starting to debug a Dart project.
I appreciate this is the wrong issue tracker for it, but I think VS Code really needs better APIs here. In addition to the bad UX, there's a perf implication - the more languages that subscribe to this, the slower pressing F5 will be as a bunch of extensions all start running activating code (and potentially spawning language servers, etc).
luabud commentedon Jan 14, 2020
I understand the concern. FWIW we're also looking into how the Python extension can be
activated faster by e.g. postponing some functionalities until they're actually needed. In this case, we wouldn't start downloading and/or executing any tools until a Python file is actually open. Then activating the extension to get the debug configuration options wouldn't be so heavy.
It's also worth mentioning that extensions can be disabled per workspace, so there's also the option to enable only the ones that are actually intended to be used on a workspace. But I also understand that this is still a problem on multi-language projects, and that not everyone is aware of this feature.
DonJayamanne commentedon Jan 14, 2020
I believe we are in a position to do this now.
If I'm not mistaken the extension loads within <1 second or perhaps <less (on my mac it takes 230ms).
The slow part in the extension is when users install extension for the first time or update it, at that point the language server gets download and blocks activation of the extension (as you have identified).
This was a deliberate decision, back then resolving this was seen as an unnecessary premature optimization. Its worked for us all these months, year, hence there was no need to optimize.
However, in light of this new requirement I believe we can make that change now - maybe.
Though we'd get prompts such as
Did you know you can change the interpreter, etc...isidorn commentedon Jan 14, 2020
Danny Tuppeny (@DanTup) please create an issue in vscode and we can continue the discussion there.
Also this event will only be fired the very first time the launch.json is getting created. It will not be fired every time a user wants to debug.
5 remaining items
JessieJolly commentedon Oct 1, 2021
Can I be assigned this issue for vGHC 21?
nayana-vinod commentedon Oct 2, 2021
Hai, I'm hoping to work on this issue with Jessica, so can I also be assigned this for vGHC21?
paulacamargo25 commentedon Oct 15, 2021
Hi Isidor Nikolic (@isidorn) im trying to test the solution. In the step 3, the "Open launch.json" in the Debug view is outdated, now we have "create a launch.json file". But if you don't have the python extension activated then you are not be able to create a launch file for python files for initial configuration.
Can you please explain how can i test that adding onDebugInitialConfigurations activation event will work?
isidorn commentedon Oct 18, 2021
launch.jsonpyfiles to make sure the python extension is not activatedcreate a launch.json file(picture)paulacamargo25 commentedon Nov 29, 2021
Fixed with #17753
isidorn commentedon Nov 30, 2021
Paula (@paulacamargo25) thanks for fixing this 馃憦