If launched is from within conda environment with "conda" installed in it, it gets called "base" which breaks the debugger

[bitplane]

Type: Bug

edit: updated

conda create -n conda-rube-goldberg --yes "python" "conda-libmamba-solver" "flake8"
conda activate conda-rube-goldberg
code .

Before debugging and launching shells, code will now run conda activate base rather than conda activate conda-rube-goldberg - see my sloppy guesswork as to why below :-)

#20224 (comment)

Extension version: 2022.18.2
VS Code version: Code 1.73.1 (6261075646f055b99068d3688932416f2346dd3b, 2022-11-09T04:27:29.066Z)
OS version: Windows_NT x64 10.0.19044
Modes:
Sandboxed: No

System Info

Item	Value
CPUs	Intel(R) Xeon(R) CPU E3-1505M v5 @ 2.80GHz (8 x 2808)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: disabled_off direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_renderer: enabled_on video_decode: enabled video_encode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: disabled_off
Load (avg)	undefined
Memory (System)	31.92GB (20.81GB free)
Process Argv	. --crash-reporter-id 92cc59cf-ad53-4daf-acd9-fbd9d55e553c
Screen Reader	no
VM	0%

A/B Experiments

vsliv368:30146709
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
pythonvspyl392:30443607
vserr242:30382549
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscoreces:30445986
pythondataviewer:30285071
vscod805cf:30301675
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
cmake_vspar411:30581797
vsaa593cf:30376535
pythonvs932:30410667
cppdebug:30492333
vsclangdf:30486550
c4g48928:30535728
dsvsc012:30540252
azure-dev_surveyone:30548225
vsccc:30610678
pyindex848cf:30577861
nodejswelcome1:30587005
fc301958:30595537
3biah626:30602489
gswce1:30605430
3d0df643:30608728
dbltrim-noruby:30604474
89544117:30607850

[karrtikr]

Thanks for the bug report! We investigate issues in order based on priority and severity, which includes the impact it has on your ability to use the extension to do productive work, and the number of people affected. If other users come forward and leave a comment demonstrating they are seeing/reproducing the problem then we will raise this issue's priority. Thanks for understanding and the patience!

[karrtikr]

Unfortunately I'm unable to reproduce the issue. In case it's helpful we calculate the 'base' environment here:

vscode-python/src/client/pythonEnvironments/common/environmentManagers/conda.ts

Line 464 in 08417ad

return 'base';

We run the conda info --json command, and check the root_prefix property there. If a prefix of the environment matches that we consider that base.

Please provide the logs as mentioned in the issue template. Set python.logging.level to debug in User settings, reload window, then perform the steps to reproduce before providing the logs.

Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)

XXX

It contains the output of the command which may be of help here.

[bitplane]

I think I was wrong, it's just that if you launch from within a Conda environment it marks the current env as the base, which breaks the debugger. If I don't, I'm in the wrong env and it breaks my tests. If I deactivate Conda entirely then things work as expected.

I'll do the debug thing but also make a minimal test case and link it here.

[bitplane]

Turns out my root_prefix has been messed up somehow, probably to do with the way I'm activating my environment in a bash shell installed by Conda in Windows. I'll investigate further, but it's not you it's me or Conda.

Thanks for the help!

Closing the issue :)

[bitplane]

I figured it out, I think I'll open it again as it's mostly Conda's fault but also maybe to do with code inconsistently calling conda.

Steps to reproduce it:

conda create -n conda-rube-goldberg --yes "python" "conda-libmamba-solver" "flake8"
conda activate conda-rube-goldberg
code .

Now open a Python file, see that flake8 can lint it, but you can't import flake8 from a debugging session!

The first line installs conda inside the environment as a dependency of conda-libmamba-solver, including putting a conda binary in the Scripts dir (which is in the path when you activate the environment). In a sane world this would completely screw conda up, but if you've done "conda init" before activating then it'll add the hook to your shell, which kludgeons over the problem so the right binary runs.

Conjecture:

At startup, code calls conda info --json and finds the version in the activated conda environment's Scripts dir, without any shell hook, which tells it that the current python.exe is in an environment called "base".

Later on, when code activates conda before starting the debugger or a shell, it calls conda activate base in the context of a shell that has the hook set up, or otherwise avoids the one under 💩/envs/conda-rube-goldberg/Scripts - causing it to activate the wrong environment. And that's what breaks the debugger!