Debug Provider to return launch configurations 'in-memory' to the debugger

[rodrigovaras]

The only way to start a debug session in vscode is by populating the launch.json content. In the 'live share' extension the launhc.json is not the only source of debug configuartions, for example when connected to a VS host there will be no launch.json file. Also live share will artificially create all the 'shared debug configurations' available on runtime without the need to change the content of launch.json.

a simple way to achieve is by something like this:

interface DebugLaunchConfigrationsProvider {
 getLaunchConfigurations(): ProviderResult<DebugConfiguration[]>;

onLaunchConfigurationsChanged: Event;
}

[weinand]

@rodrigovaras your proposed "simple way" API returns the contents of launch configs which makes it easy to merge 'in-memory' launch configs for use in VS Code's drop down menu.
But the API does not make clear how a user would interact with those 'in-memory' launch configs.
Normally a user can open any launch config for editing or viewing (by selecting it in the drop down and then pressing the gear button).

If I understand your approach correctly then you want to use the proposed API to "share" launch configs between host and runtime by replicating them. So the launch configs are not really dynamically created "new" launch configs, but they are just read from some other location.
This 'in-memory' approach results in the problem that launch configs cannot be easily viewed and edited because their original source (the launch.json) is not available.

What do you think about an alternative API where you could directly specify the location of the launch.json? With this approach VS Code could transparently support viewing and editing of remote locations.

/cc @isidorn

[rodrigovaras]

Adding @jramsay which is now maintaining that part of code.
Probably you are right, the original proposed API would have troubles when editing remote configurations, i was hoping the vscode could somehow handle the in-memory experience in coordination with our live-share file system provider. But that approach has multiple issues since it will break our co-editing story.
What we have today is a shared service that would return all the supported configurations and the joined session will expose the configurations through the file system provider, Through co-editing the user should be able to edit remote configurations by looking into file system tree, we also detect updates when he saved them.
In summary, we did support showing the remote configurations and also making changes on them if the user know where to locate them. I'm sure we can improve the experience, i leave to jason to decide if we want a more elaborated solution that could require your help on the vscode side.

[rodrigovaras]

The real issue to resolve on our case is how we can expose on the guest side a good way to show the current ‘shared’ debugged sessions. This is different from launching a new debug session from the guest side, but a way to connect to existing co-debug sessions after you disconnect from them, basically how we can re attach to an existing session.

To explain this better,

• No debug session on both shared/joined side
• Host expose 2 debug configurations
• Guest see those 2 debug configurations
• Any of them could start a debug session, let’s say host start it
• Guest vscode attach to the co-debug session automatically but then decided to leave the session (or it could have a settings which has the ‘auto join’ == false)
• What should see the guest side ? (3 launch configurations , 2 to launch a new session, 1 to reattach)
• That additional ‘running co-debug session’ only make sense on the guest side and should not be editable

Today we offer a not very intuitive mechanism to reattach, by selecting a command that offer some quick options, I don’t think nobody could figure out easily.
Would be nice if we can dynamically add this additional ‘running’ session into the Debug drop down and when selected it would re-attach into the existing session.

[weinand]

@rodrigovaras you said:

"Would be nice if we can dynamically add this additional ‘running’ session into the Debug drop down and when selected it would re-attach into the existing session."

Is it correct that you do not really need a "dynamically created launch config" showing up in the drop down but that adding "custom commands" to that drop down would be sufficient?
Those commands would have the advantage that they are direct actions which would not require the user to select a config first and then press the green "Run" button.

The drop down could look like this:

[rodrigovaras]

Yes, that would be enough, sounds like a great solution.
A couple of comments:

• On select the option we would show the quick info of the available running session
• Or we may want to display multiple commands for each session with good description on what debug session is being referred (ex. Live Share- Attach to 'Node Web App 1')

[isidorn]

Hi Rodrigo, I am Isidor and I work with Andre on debug in VSCode.

We could add the command in the debug dropdown as Andre sketched out and that would mean we are adding a new contribution point.
However I am against this approach unless we find more extensions that have a similar use case.

Since Live Share has its own viewlet, why don't you add this action to the top inside the LiveShare viewlet?
An alternative idea is that you contribute an editor title action for launch.json files. So it would live in the top right of the editor - since that area is already contributable.

[rodrigovaras]

These are good alternatives, adding @lostintangent to comment.

[lostintangent]

Since the Live Share viewlet represents the “command center” for all things shared in the collaboration session, the intention was to eventually display the list of active debug sessions in it, much like we already do for terminals, servers, etc.

So if folks think that’s the right approach, then that sounds great to me 👍 We can discuss the experience on our end, and presumably have all the APIs we would need?

[isidorn]

If you would display a list of active debug sessions there than it absolutetly makes sense to put this action there. If I understand correctly you would use Tree api to show all sessions, and every tree item can have an action next to it. The action could be "Attach to Session" with some nice icon (similar how the SCM viewlet shows actions on the right of every item).

[weinand]

With feature #88230 dynamic (aka 'in-memory') launch configurations are supported via the DebugConfigurationProviderAPI.
So this feature request has been addressed.