Debug test does not load env variables from conda

[giacomorebecchi]

Type: Bug

Behaviour

Expected vs. Actual

Expected: if I set the python interpreter for a workspace as a conda env built from an environment.yml file that specifies some environment variables through the variables keyword, I would like to have those variables set when I run code through the Python debugger VSCode extension.

Actual: the env variables are not set when running code from the VSCode debugger.

Note that I experienced the error while debugging tests using pytest.

Steps to reproduce:

1. Create a conda environment through an environment.yml with variables keyword specifying some env vars
2. Select as interpeter such a conda env for the workspace
3. Write a test that checks that the env vars are correctly set
4. If you run the test from the terminal using pytest, the test passes
5. If you debug the test, the env vars are not found

Diagnostic data

• Python version (& distribution if applicable, e.g. Anaconda): 3.9.16
• Type of virtual environment used (e.g. conda, venv, virtualenv, etc.): Conda
• Value of the python.languageServer setting: Default

User Settings

languageServer: "Pylance"

linting
• flake8Args: "<placeholder>"
• flake8Enabled: true

formatting
• provider: "black"

testing
• pytestArgs: "<placeholder>"
• pytestEnabled: true

Extension version: 2023.2.0
VS Code version: Code 1.75.1 (441438abd1ac652551dbe4d408dfcec8a499b8bf, 2023-02-08T21:32:34.589Z)
OS version: Windows_NT x64 10.0.22621
Modes:
Sandboxed: No
Remote OS version: Linux x64 5.15.0-1028-aws

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz (8 x 1992)
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)	7.85GB (1.32GB free)
Process Argv	--crash-reporter-id 9642e38f-e1aa-4799-ba32-b1383b4b1c29
Screen Reader	no
VM	0%

Item	Value
Remote	SSH: GR.Dev
OS	Linux x64 5.15.0-1028-aws
CPUs	Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz (2 x 2499)
Memory (System)	7.66GB (6.12GB free)
VM	0%

A/B Experiments

vsliv368:30146709
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vswsl492cf:30256860
vslsvsres303:30308271
pythonvspyl392:30443607
vserr242:30382549
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263cf:30335440
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
pynewvextcfv2:30660300
azure-dev_surveyone:30548225
vsccc:30610678
pyindex848cf:30577861
nodejswelcome1cf:30587006
2e4cg342:30602488
f6dab269:30613381
pythonsymbol12:30657548

[karrtikr]

Thanks for the bug report! We just wanted to quickly acknowledge we received it and we will triage this as soon as we can.

[karrtikr]

Try adding the following configuration to your launch.json file:

{
  "name": "Debug Unit Test",
  "type": "python",
  "request": "launch",
  "purpose": ["debug-test"],
  "console": "integratedTerminal",
},

This makes sure we use integrated terminal instead of internal console when debugging tests, where the environment variables are already loaded.

[karrtikr]

#8422 should help fix the error when using internal console.

[giacomorebecchi]

@karrtikr thanks for suggesting a workaround!

[karrtikr]

@eleanorjboyd @karthiknadig Is there any particular reason why we prefer to use internalConsole as default instead of integratedTerminal when debugging tests. Considering in normal debugging scenarios terminal is used by default.

[eleanorjboyd]

deferring to @karthiknadig for this answer

[karthiknadig]

Tests are often run in the background. So, we use internalConsole, in an attempt to preserve the manner in which we discover and run tests without debugger.

[karrtikr]

I see, given there's nothing to change, closing this issue in favor of #8422. Feel free to upvote that to raise priority.