Repository navigation
Use 'conda run' when debugging user code #8422
Description
Activity
To make this work,
LaunchRequestArguments.pythonPathis deprecated in the debugger. Remove all occurences of"pythonPath"is the extension.- Check conda version to make sure
conda runcommand is supported. - If the current interpreter is conda, fetch two things.
<path to conda.exe>: UsecondaService.getCondaFile()to do that.Name and path of the conda environment: UsecondaService.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 runcommand 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 useconda run -n base python -- <...>`as
pythonis able to parse double dashes.- Edit
package.jsonto support intellisense for"python"inlaunch.json. Also make sure to remove intellisense for"pythonPath".
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.
Kim-Adeline Miguel (@kimadeline) Karthik Nadig (@karthiknadig) /ccIf 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".
Pavel Minaev (@int19h) Oh right. Edited the issue accordingly.
Don Jayamanne (@DonJayamanne) I added that we need to check conda version only to check ifconda runis supported.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 .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.Reacted by Don JayamanneMake sure that when we test this, we also test it with auto-activate terminal setting turned on.
Shouldn't we use
conda activatethen run python code, instead of conda run?
I thinkconda runwould work when not running in a terminal, but when in a terminalconda activatewould be betterElse user output won't be displayed in terminal,
inputwill not work, etc..Don Jayamanne (@DonJayamanne) this is for calling the debugger, not running python code
calling the debugger, not running python code
But with the way debug adapter is designed, why do we even need to run the adapter with conda run!
The adapter doesn't run any user code? So it's not necessary at all.
It's the process that's launched by the adapter that needsconda environmentThat's exactly what the proposal does: "python" is a property that gets parsed by the adapter; or rather by the launcher, which is spawned by the adapter via "runInTerminal" request to VSC. The launcher then applies it when spawning the debuggee. Neither the adapter nor the launcher run in the activated environment.
Are you saying that the debuggee needs to be spawned using
conda activaterather thanconda run, due to conda/conda#8386? It looks like they have fixed the issue with redirection recently, so I don't know if we have to worry about that anymore.If we do, I'm not sure how we can pull that off. We'd need to issue
conda activatefirst as a separate "runInTerminal" request, but the problem with those is that VSC sends the response to it as soon as the command starts running - there's no way for them to tell when it actually completes, though. So if we just send two requests sequentially, I don't think that'll do the right thing.6 remaining items
To clarify, what I'd like to avoid is having to re-implement all of this:
https://github.com/microsoft/vscode/blob/f395cac4fff0721a8099126172c01411812bcb4a/src/vs/workbench/contrib/debug/node/terminals.ts#L79-L210To clarify, what I'd like to avoid is having to re-implement all of this:
I agree, there's more to this (keeping track of terminals, etc). And that's something we wanted to avoid in core extension team (back when I was there). Brett Cannon (@brettcannon) is aware of these discussions.
Pavel Minaev (@int19h) Had a chat with Karthik Nadig (@karthiknadig) about an alternative. Creating a terminal with the right environment variables. This might help https://github.com/microsoft/vscode-python/issues/8928
Based on chats with the team:
-
The gist of what we need to do is set the
pythonfield in the launch configuration to the[ "conda" , "run", "-n", "env_name", "--no-capture-output", "python"]and set the
adapterPythonto whatever python executable we want. -
This means it'll also use this command to run the launcher, unless we specify
"debugLauncherPython", so it will show up as"conda run"in the terminal, which is what the users might expect. However note it does mean that we'll spawn "conda run" from inside another "conda run", which is very recently fixed Running usingconda runinside already activated environment should be the same as running it outside conda/conda#11305. -
So we are waiting on conda to let us know their support timelines based on we can start using this approach.
With #20651 we're now using
conda runto get environment variables in cases where some otherpythonis explicitly specified by user. We should remove this with this issue.-
We're currently getting env variables using conda run and applying to debugging or executing #20651, which also has been working well. Hence closing as not required for now.
We're currently getting env variables using conda run and applying to debugging or executing #20651, which also has been working well. Hence closing as not required for now.
And I assume this won't be a concern when debugging is launched from the Python Debugger extension or if people turn off the terminal activation feature?
That's right, we intercept and add the env variables independently of the experiment.
- locked as resolved and limited conversation to collaborators
on Oct 14, 2023
Work item associated to the spike #8421