Startup script for temporary interactive console debug sessions

[hmmwhatsthisdo]

System Details

• Operating system name and version: Windows 10 x64 (Multiple builds)
• VS Code version: 1.19.2
• PowerShell extension version: 1.5.1
• Output from $PSVersionTable:

Name                           Value
----                           -----
PSVersion                      5.1.15063.786
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.15063.786
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

PS C:\> code -v
1.19.2
490ef761b76b3f3b3832eff7a588aac891e5fe80
x64
PS C:\> $pseditor.EditorServicesVersion

Major  Minor  Build  Revision
-----  -----  -----  --------
1      5      1      0


PS C:\> code --list-extensions --show-versions
[email protected]
PS C:\> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.15063.786
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.15063.786
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Issue Description

As it stands, debugging a module in VSCode is still a bit clunky. Debug configurations allow for generating a temporary integrated console for every debug session, but using this option requires manually importing the module every debug session.

There is also the option of running a script via the script attribute in a debug configuration entry, which could potentially be used to run environment setup (module import, etc.) - however, the integrated console closes once the script completes. It would be helpful if there was a way to specify a startup script for temporary consoles in a debug configuration, so module imports and whatnot could be done automatically.

[hmmwhatsthisdo]

After speaking with @seeminglyscience on the PowerShell Slack team, it sounds like most of the work needed for this would be on the PSES side - however, I'm having trouble figuring out specifically what would need to be implemented on the PSES side vs. what would need to be implemented here.

[rkeithhill]

There is already a startup script Microsoft.VSCode_profile.ps1 . It just is a user thing instead of a workspace thing. Given the way the PSIC works now, any sort of "startup" only needs to be run once because the language session and all debug sessions share the same PowerShell instance. You can see this with $pid in the PSIC at various phases of its use. Unless you are using temp integrated consoles, which disappear before you get a chance to check your output. :-(

That said, I do think it would be nice to have a workspace specific startup script or maybe even a workspace profile. The downside to a startup script is that we'd need to make that a setting and then we'd need to pass the path to the startup script from the extension to PSES (not a big downside mind you). If we made it a profile, it would have a specific name and if it existed it would just get run with no need to specify any extension setting. Either way, at this time, the default behavior would be that it runs once, when PSES first starts.

For a temp integrated console, perhaps a workspace profile could access variables to let you know which debug launch config is currently active. This is where I dither a bit. Is it easier to have a single workspace profile that could tell the diff between lang/debug sessions and know which debug config (name?) is active and then put all your logic in there to handle different debug scenarios. Or is it easy to have a property on the debug launch config where you specify a path to various startup scripts.

[SeeminglyScience]

I believe he's talking mostly about temporary interactive debugging sessions which is where an init script would be the most helpful.

Or is it easy to have a property on the debug launch config where you specify a path to various startup scripts.

That was my thought. I can see that potentially being useful for all debug configuration types, but in particular temp interactive sessions. Assuming that's a reasonably easy property to add, I think that's the best way to go.

About workspace profiles, I really like the idea of them for preparing intellisense/loading editor commands from #190. I think mixing debugging into that, or having a separate profile for it might be confusing.

[rkeithhill]

I think mixing debugging into that, or having a separate profile for it might be confusing.

Well for the vast majority of folks that will not discover the temp int console setting, such a profile would mix with debugging. Maybe that setting should be a setting on the launch configuration instead - at least for configs like launch script, current file and current file w/args. We also really, really need to fix the behavior that the temp console closes immediately after the script finishes.

[hmmwhatsthisdo]

@rkeithhill, @SeeminglyScience: I totally neglected to mention I was talking about the temporary interactive console - whoops! I'm editing the issue text now.

Or is it easy to have a property on the debug launch config where you specify a path to various startup scripts.

This is what I think would be the easiest from a usability perspective - that, or re-use the current script attribute on debug configurations and add an attribute similar to PoSH's -NoExit switch.

[mud5150]

I would also love to see this happen. Using the createTemporaryIntegratedConsole reduces the side effects from loading the module multiple times. I would love to also have some way to have it load the module into the temp console when I hit debug.

[JustinGrote]

@SydneyhSmith this should probably be reclassified to an enhancement.

[mdgrs-mei]

Now it seems that the temporary integrated console does not close after the script finishes which means it could be used as a startup script.

I'm using [email protected].