Activity

1. ghost added

   triage-neededNeeds assignment to the proper sub-teamNeeds assignment to the proper sub-team

   on May 17, 2019
2. Don Jayamanne (DonJayamanne)

   self-assigned this

   on May 17, 2019
3. Don Jayamanne (DonJayamanne)

   added

   area-terminal

   needs upstream fix

   importantIssue identified as high-priorityIssue identified as high-priority

   reason-preexisting

   bugIssue identified by VS Code Team member as probable bugIssue identified by VS Code Team member as probable bug

   upstream-vscode

   on May 17, 2019
4. ghost removed

   triage-neededNeeds assignment to the proper sub-teamNeeds assignment to the proper sub-team

   on May 17, 2019
5. ghost removed

   triage-neededNeeds assignment to the proper sub-teamNeeds assignment to the proper sub-team

   on May 17, 2019
6. Don Jayamanne (DonJayamanne)

   removed their assignment

   on Jun 24, 2019
7. Don Jayamanne (DonJayamanne)

   removed

   needs upstream fix

   upstream-vscode

   on Jun 24, 2019
8. ghost added

   triage-neededNeeds assignment to the proper sub-teamNeeds assignment to the proper sub-team

   on Jun 24, 2019
9. ghost added

   triage-neededNeeds assignment to the proper sub-teamNeeds assignment to the proper sub-team

   on Jun 24, 2019
10. 9 remaining items

    Load more

11. ericsnowcurrently commented on Jul 9, 2019

    

    Eric Snow (ericsnowcurrently)

    on Jul 9, 2019

    More actions

    To try this out, I added the following to src/client/debugger/debugAdapter/DebugClients/LocalDebugClient.ts (right before the existing const termArgs: ... line in launchExternalTerminal():

                    if (!isExternalTerminal) {
                        const termArgs: DebugProtocol.RunInTerminalRequestArguments = {
                            kind: consoleKind,
                            title: 'Python Debug Console',
                            cwd: cwd,
                            args: ['echo', 'spam'],
                            env: env
                        };
                        this.debugSession.runInTerminalRequest(termArgs, 5000, (response) => {
                            if (response.success) {
                                resolve();
                            } else {
                                reject(response);
                            }
                        });
                    }

    Unfortunately, it opened a separate terminal for each request. We we're back to the drawing board.

    The only other realistic solutions (without upstream changes):

    • generate a shell script that contains the two shell invocations (requires quoting the args)
    • add a static script that supports executing multiple "argv"s, e.g. separated by a semicolon
12. ericsnowcurrently commented on Jul 15, 2019

    

    Eric Snow (ericsnowcurrently)

    on Jul 15, 2019

    Last edited by ericsnowcurrently

    More actions

    I ran into the following problems:

    A. DebugSession.runInTerminalRequest() does not support re-using a terminal from an earlier call; so we can't just call that API once for activation, followed by once for the debugger
    B. runInTerminalRequest() does not support sending multiple commands (sort of)
    C. we can't use runInTerminalRequest() directly for activation commands (they do things like "source" and runInTerminalRequest() prepends the env vars to the "command" string that gets executed, which is incompatible with "source")
    D. getting the activation commands to the debugger isn't trivial

    So we have a few options at this point if we want to activate environments:

    1. make the status quo work (via TerminalAutoActivation)
       • none of the above problems
       • complicated and maybe not even possible
    2. do as much as possible in the debugger
       • keeps the debug adapter code in the debug adapter
       • suboptions dealing with problem D:
         a. pass the activation commands via the launch config
         - requires getting them into the config dynamically
         b. use a custom DAP request to get the activation commands from the extension
         - only custom events are currently supported?
         c. use a custom DAP event to request the activation commands from the extension
         - we already have the machinery in the extension for custom DAP events
         - how to get them back? through a file?
       • suboptions to deal with problems A, B, and C:
         d. wrap activation commands and debugger command in a script to run via runInTerminalRequest()
         - requires a temporary shell script written to disk
         - requires quoting, etc.
         e. add a static script that decodes its args into multiple commands and runs them
         - takes advantage of VSC arg quoting, etc.
         f. (upstream) get runInTerminalRequest() updated to solve the problem
         - support multiple requests against the same terminal (by PID or some other ID)
         - (or support passing multiple commands in a single request)
         - support "source", etc commands (move env vars to end?)
         g. chain the commands (e.g. with && or ;) and wrap the whole thing in e.g. sh -c ""
       • suboptions to deal with problems A, and B:
         h. chain commands, e.g. with && or ;
         - env vars might only apply to the first command (need to check)
       • suboptions to deal with problems C:
         i. chain the activation command with a preceding noop (e.g. true && source ...)
         - env vars might only apply to the first command (need to check)
    3. do as much as possible in the extension
       • not affected by the problems from above
       • solution (in debug adapter):
         • add a way to trigger starting the debugger from the extension (via the debug adapter protocol)
           1. use a custom DAP request
              • only custom events are currently supported?
           2. use a custom DAP event
              • we already have the machinery in the extension for custom DAP events
              • how to indicate ready? through a file?
         • trigger that event/request (send debugger command and env vars)
         • wait for the debugger to start (necessary for some internal VSC debugger functionality)
       • solution (in extension)
         • add DAP event handler
         • create terminal
         • activate environment in terminal (like normal)
         • run debugger command in terminal
         • notify debug adapter

    Might be necessary:

    • generate activation commands as multiple argv (string[][]) instead of a single string
      • necessary for use with spawn and
      • conda
      • pipenv
      • pyenv
      • venv, etc.

    Other notes:

    • runInTerminalRequest works like a cross between child_process.exec and spawn
      • the API requires passing args: string[]), but the eventual execution is a single string sent to the shell
      • we could do clever things like include && as an arg, since it gets run in a shell (but I'm not sure what guarantees we have
      • composes a string for the string[] command/args
        • includes the env vars (at the beginning of the string)
        • quotes each argument where necessary
        • not compatible with source
      • chain of calls:
        • https://github.com/microsoft/vscode/blob/08e8d4633f5284de9a1115bccb314620d0a5a06b/src/vs/workbench/contrib/debug/browser/rawDebugSession.ts#L537
        • https://github.com/microsoft/vscode/blob/08e8d4633f5284de9a1115bccb314620d0a5a06b/src/vs/workbench/contrib/debug/common/debugger.ts#L110
        • https://github.com/microsoft/vscode/blob/08e8d4633f5284de9a1115bccb314620d0a5a06b/src/vs/workbench/contrib/debug/browser/debugConfigurationManager.ts#L111
        • https://github.com/microsoft/vscode/blob/08e8d4633f5284de9a1115bccb314620d0a5a06b/src/vs/workbench/api/browser/mainThreadDebugService.ts#L74
        • https://github.com/microsoft/vscode/blob/08e8d4633f5284de9a1115bccb314620d0a5a06b/src/vs/workbench/api/node/extHostDebugService.ts#L317
        • (line 351) convert env vars and argv to single quoted string
        • (line 352) call terminal.sendTest()
    • the serverReadyAction launch config depends on the terminal identified by the runInTerminal request--so it could mean that we have to use runInTerminal (but other extensions don't run in terminal, so maybe not)
13. Don Jayamanne (DonJayamanne)

    modified the milestones: 2019 - June Sprint 13, 2019 - July Sprint 14 on Jul 17, 2019
14. Don Jayamanne (DonJayamanne)

    unassigned

    Eric Snow (ericsnowcurrently)

    on Jul 17, 2019
15. Kartik Raj (karrtikr)

    changed the title [-]Activation script sent to terminal after debugger starts[/-] [+]Spike - Activation script sent to terminal after debugger starts[/+] on Jul 31, 2019
16. karrtikr commented on Jul 31, 2019

    

    Kartik Raj (karrtikr)

    on Jul 31, 2019

    Last edited by DonJayamanne

    More actions

    Spike

    • Will using conda run work in terminal (works, this is a documented solution)
    • Will using conda run in background process work (spawn('conda run xyz.py')), i.e. we're not running in a terminal.
    • Will using <fully qualified path to conda executable> run work` in terminal
    • Will using <fully qualified path to conda executable> run work` in background process.
17. Kartik Raj (karrtikr)

    changed the title [-]Spike - Activation script sent to terminal after debugger starts[/-] [+]Spike - Activation script sent to terminal after debugger starts (Use Conda run)[/+] on Jul 31, 2019
18. Don Jayamanne (DonJayamanne)

    modified the milestones: 2019 - July Sprint 14, 2019 - July Sprint 15 on Jul 31, 2019
19. Don Jayamanne (DonJayamanne)

    self-assigned this

    on Aug 5, 2019
20. Don Jayamanne (DonJayamanne)

    closed this as completedon Aug 5, 2019
21. ghost removed

    needs PR

    on Aug 5, 2019
22. ghost removed

    needs upstream fix

    on Aug 5, 2019
23. lock

    locked as resolved and limited conversation to collaborators on Aug 12, 2019