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
Debugger commands sent to terminal get swallowed by previous terminal command #67692
Add a python file with a simple print("Hello") statement
Open the terminal in VSC and type the command pipenv shell
This will create a virtual environment for the current folder
Open another terminal and notice how the Python extension will automatically add pipenv shell, causing the previously created environment to get activated in this new terminal.
Reload VSC
The above pipenv environment will now be automatically selected
If not, please use the command Select Python Interpreter
From the list, of interpreters select the interpreter with the name same as the folder name you are in.
Debug the python file
The terminal will now open automatically
Python Extension will send the text pipenv shell to activate the environment in the terminal
VSC Debugger sends the necessary commands to the terminal
Unfortunately there's a race condition here, pipenv shell has not yet completed, and the commands sent by VSC debugger get swallowed up
End result, debugger doesn't start
Causes:
There's no way to determine when terminal has completed processing previously sent commands.
VSC is sending messages to the terminal, when its busy
Solutions:
Python extension can take complete control of opening terminals, etc and not use runInTerminal request (i.e. python extension re-invent the wheel).
VSC DAP accepts additional commands that need to be invokved in the runInTerminal request.
Currently we can only send args, how about extending this to send commands as well.
This way the extension can send some custom commands that need to be executed before the VSC debugger commands. I.e. chain them together.
To help kickstart this again, the two ideas we had today for solving our debugger issues (if you all would be so gracious as to implement one of them 😉 ) are:
Provide a way for us to specify the terminal ID to have the debugger run into (so we can make sure the terminal is already activated for the Python virtual environment)
Open up an API to the code that constructs the command that gets sent into the terminal (so we can dynamically construct a shell script of two lines -- one to activate, one to run the debugger - so everything is quoted appropriately in the shell script and then we have the terminal run the shell script to make sure everything completes appropriately serially)
I haven't really looked into DAP much, but I had a look at how runInTerminal works. You might be able to pass in this as the first arg in the args array to string together multiple commands?
Linux/macOS: sh -c "pipenv shell && debug"
Windows: cmd.exe /k ... or equivalent in PS
Also created #77110 and #77111 after looking into the feature.
Will that quote what's in those quotes correctly? E.g. if one of the args that you need has a space will that get quoted appropriately in that string you pass to sh?
Activity
Tyriar commentedon Feb 1, 2019
See #67693 (comment)
brettcannon commentedon Jul 9, 2019
To help kickstart this again, the two ideas we had today for solving our debugger issues (if you all would be so gracious as to implement one of them 😉 ) are:
Tyriar commentedon Jul 10, 2019
I haven't really looked into DAP much, but I had a look at how runInTerminal works. You might be able to pass in this as the first arg in the
argsarray to string together multiple commands?sh -c "pipenv shell && debug"cmd.exe /k ...or equivalent in PSAlso created #77110 and #77111 after looking into the feature.
brettcannon commentedon Jul 10, 2019
Will that quote what's in those quotes correctly? E.g. if one of the args that you need has a space will that get quoted appropriately in that string you pass to
sh?Tyriar commentedon Jul 10, 2019
Brett Cannon (@brettcannon) provided the quotes get escaped correctly in debug I would think so.
weinand commentedon Jul 26, 2019
I've fixed issues #77110 and #77111, but they don't really help with the issue at hand.
As Daniel Imms (@Tyriar) has pointed out in #67693 (comment), there is not much we can do here. His recommendation in #67692 (comment) is the way to go.
Quoting should work fine; if not, please file separate issues for them.