Python extension should activate on onDebugInitialConfigurations

[isidorn]

Hi VS Code dev here 👋

1. Have python extension installed, workspace without a launch.json.
2. Do not open a python file
3. Press "Open launch.json" in the Debug viewlet
4. 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.

fyi @luabud

[DonJayamanne]

@isidorn
Wouldn't this cause the extension to load even if the user is about to debug a js or c# file?
If that's the case, I would have thought that is not a desirable feature as this could unnecessarily slow the experience for users when they don't want to debug python files.

Please ignore my comments, that's the other older event ondebug

[DanTup]

I don't know if it's changed, but I had a niggle with onDebugInitialConfigurations mentioned here:

microsoft/vscode-node-debug#170

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 @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]

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 @DanTup is describing is a corner case and python should be in the same spot as the js debuggers.

[luabud]

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]

the event @DanTup is describing is a corner case

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]

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]

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...