Custom config for testing and debug v2 design

[cwebster-99]

In previous iterations we created a V1/MVP for a custom config design for testing and debugging. In this upcoming iteration we will work on iterating for a V2

• [x] Synthesize feedback from V1
• [x] Create new list of technical/non-technical requirements
• [ ] Meet with team to discuss integration

[eleanorjboyd]

The following is the new V2 design as formulated by @cwebster-99 and I. These would be found / placed in the launch.json

design for testing

{
      "name": "default test config on UI creation",
      "type": "debugpy", ?
      "request": "launch",
      "purpose": ["discover-test", "run-test", "debug-test"],
      "presentation": "hidden",
} // This is what would happen if a user went through the basic setup flow
{
      "name": "discovery or execution, all possible attributes",
      "type": "python", ?
      "request": "launch",
      "purpose": ["discover-test"],
      "presentation": "hidden",
      "args": []
      "env" : {},
            "cwd" : '',
            "envFile" : '',
} // These are all possible attributes allowed if the type is "discover-test" or "run-test"
// if user also has debug-test the others will be possible but will not impact discovery or run 
// unless these attributes are explicitly listed as test supported

debug test

For "debug-test" allow all attributes currently supported by the python debugger

justMyCode
console
autoReload
consoleTitle // core
debugAdapterPath
debugServer //core
gevent
internalConsoleOptions // core
linux // check
logToFile
osx // check
pathMappings
postDebugTask // core
preLaunchTask // core
presentation
redirectOutput
serverReadyAction
showReturnValue
stopOnEntry
subProcess
suppressMultipleSessionWarning //core
windows // check
pythonArgs // check with Karthik ( pass to the interpreter itself)
args
pyramid
module ?
env 
cwd
envFile
program 
framework: [jinja, django] //debugpy, I can decide settings.json vs debugpy
host
port
sudo
listen
connect

Run button / non-test scenarios

{
      "name": "run config for file run button",
      "type": "python", ?
      "request": "launch",
      "presentation": "hidden",
     "noDebug": "true"
} 

Here a user could specify they do not want a launch.json config to be used for debugging but again an opt out instead of an opt in scenario.

Questions:

1. What should the type be for the multiple different configs? Having something of type "debugpy" doesn't really make sense when the purpose is just "test-discovery" or "test-run"
2. What do people think of "noDebug" as a specification? Do we think this is another opt out parameter that is non-default? Is that the right name for it?
3. Is hidden our desired default for all config types?
4. What happens if someone includes a param like "justMyCode" but do not debug? How do we signal that will not be used?

[cwebster-99]

What do people think of "noDebug" as a specification? Do we think this is another opt out parameter that is non-default? Is that the right name for it?

Along these lines, one more consideration is on the Run button / non-test scenarios should we be including purpose: "run", "debug" by default or just use nodebug attribute to control when something is run and debug vs not. I am not sure how discoverable this maybe or if we should standardize with the test configs. It might be a bit redundant to have purpose and nodebug...Looking for thoughts :)

[cwebster-99]

Notes/Edits after discussion:

• Switching to type: "python-test", and make "purpose" optional, default value for purpose is all 3 (opt-out)
• "presentation": "hidden" is default for test configs but not for debug and run
• Testing framework is defined at workspace settings level and not defined in the launch configs
• If attributes dont apply to the configs we will put a warning squiggles in the logs

[cwebster-99]

These would be found / placed in the launch.json

design for testing

{
      "name": "default test config on UI creation",
      "type": "pythonTest", 
      "request": "launch",
      "presentation": "hidden",
} // This is what would happen if a user went through the basic setup flow
{
      "name": "discovery or execution, all possible attributes",
      "type": "pythonTest", ?
      "request": "launch",
      "purpose": ["discover-test"],
      "presentation": "hidden",
      "args": []
      "env" : {},
            "cwd" : '',
            "envFile" : '',
} // These are all possible attributes allowed if the type is "discover-test" or "run-test"
// if user also has debug-test the others will be possible but will not impact discovery or run 
// unless these attributes are explicitly listed as test supported

debug test

For "debug-test" allow all attributes currently supported by the python debugger

justMyCode
console
autoReload
consoleTitle // core
debugAdapterPath
debugServer //core
gevent
internalConsoleOptions // core
linux // check
logToFile
osx // check
pathMappings
postDebugTask // core
preLaunchTask // core
presentation
redirectOutput
serverReadyAction
showReturnValue
stopOnEntry
subProcess
suppressMultipleSessionWarning //core
windows // check
pythonArgs // check with Karthik ( pass to the interpreter itself)
args
pyramid
module ?
env 
cwd
envFile
program 
framework: [jinja, django] //debugpy, I can decide settings.json vs debugpy
host
port
sudo
listen
connect

Run button / non-test scenarios

{
      "name": "run config for file run button",
      "type": "debugpy", 
      "request": "launch",
     "noDebug": "true"
} 

Debug configs remain unchanged :)