Use 'conda run' when debugging user code

[kimadeline]

Work item associated to the spike #8421

[karrtikr]

To make this work,

• LaunchRequestArguments.pythonPath is deprecated in the debugger. Remove all occurences of "pythonPath" is the extension.
• Check conda version to make sure conda run command is supported.
• If the current interpreter is conda, fetch two things.
  • <path to conda.exe> : Use condaService.getCondaFile() to do that.
  • Name and path of the conda environment : Use condaService.getCondaEnvironment() to fetch that.
    Now add this to the launch configuration in the debug resolver,

{
    "name": "Python: Current File",
    "type": "python",
    "request": "launch",
    "program": "${file}",
    "console": "integratedTerminal",
    "python": ["<path to conda.exe>", "run", "-n","<name of environment>", "python"] // <--- This is what you will have to add if conda environment has a name
}

OR

{
    "name": "Python: Current File",
    "type": "python",
    "request": "launch",
    "program": "${file}",
    "console": "integratedTerminal",
    "python": ["<path to conda.exe>", "run", "-p","<path to environment>", "python"] // <--- This is what you will have to add if conda environment has does not have name
}

• If the current interpreter is not conda, you have to add "python": <path to the selected python interpreter> in the launch resolver. This is because debugger expects 'python' must have at least 1 element.
• In earlier versions, one could use double dashes in conda run command to separate CLI flags for clarity. Something like,

conda run -n base -- python <...>`

But it seems support for that has been deprecated in conda. However one could still use

conda run -n base python -- <...>`

as python is able to parse double dashes.

• Edit package.json to support intellisense for "python" in launch.json. Also make sure to remove intellisense for "pythonPath".

[DonJayamanne]

If the current interpreter is conda, fetch two things

Please ensure we re-use existing code instead of hardcoding logic in other places.
As it is, we have 3 rules (if cond, if env name, if env path) in this place and we have missed one crucial rule (checking version of conda). Hence the need to re-use code.
@kimadeline @karthiknadig /cc

[int19h]

If the current interpreter is not Conda, the extension should provide the full path to the corresponding Python binary in "python", just like it did before via "pythonPath".

In the common case of a single value, it can be specified directly - i.e. "python": "foo" is the same as "python": ["foo"]

But note that "python" is a ptvsd 5 thing, so none of this should kick in if the older version is in use - it should continue to use "pythonPath".

[karrtikr]

@int19h Oh right. Edited the issue accordingly.
@DonJayamanne I added that we need to check conda version only to check if conda run is supported.

[DonJayamanne]

Still unsure why we're documenting an existing logic. what if another is missed again.
Also this solution implies we write this code again, instead of re-using... Anyways, thats my opinion .

[karrtikr]

Oh I see what you're saying.
Was just documenting to make sure we don't forget about it. We'll definitely try to re-use existing logic where we can.

[karthiknadig]

Make sure that when we test this, we also test it with auto-activate terminal setting turned on.