Debugpy won't pick up (conda) virtual environments.

[ubaldot]

I am using debugpy along with Vimspector.

I am wondering if there is a way to tell debugpy to use a specific virtual environment (FYI: I am using conda).
I have the following config:

    "Python run generic script (venv problems)": {
      "configuration": {
        "request": "launch",
        "program": "${file}",
        "cwd": "${fileDirname}",
        "stopOnEntry": true,
        "console": "integratedTerminal",
        "autoReload": {
        "enable": true
        },
      }
    },

and in my python code I have the following two lines:

import numpy as np
import matplotlib.pyplot as plt

The first line runs correctly, but from the scope window I see that numpy is picked from the wrong location:

*+ np: <module 'numpy' from '/Users/ubaldot/Library/Python/3.9/lib/python/site-packages/numpy/__init__.py'>

instead of being taken from /opt/homebrew/Caskroom/miniconda/base/envs/dymoval_dev/pkgs/numpy-1.24.3-py311hb8f3215_0/lib/python3.11/site-packages/numpy.

In-fact, in the second line I get matplotlib module not found error which is normal, given that it is not installed in /Users/ubaldot/Library/Python/3.9/lib/python/site-packages.

By typing where python from a zsh opened inside Vim, I get /opt/homebrew/Caskroom/miniconda/base/envs/dymoval_dev/bin/python, thus suggesting that the surrounding environment around debugpy is correct.

How to fix this issue? I checked the debugpy docs and it does not seem there is any other options that I may tweak.
The only one I found was "python" that I set to point to the python installed in /opt/homebrew/Caskroom/miniconda/base/envs/dymoval_dev/bin/python but debugpy still picks numpy from /Users/ubaldot/Library/Python/3.9/lib/python/site-packages/numpy.
The debugpy version used by Vimspector is 1.8.1.

I am starting Vim from the correct conda environment and I also have conda activate dymoval_dev in the .zshrc file.

[int19h]

You can specify the path to Python interpreter to use to launch your code in your debug config like so:

"python": ".../bin/python3"

If you point it at the Python binary/symlink that is under Scripts in the env, it should take care of environment activation for regular venvs.

For Conda this is not sufficient, because its activation scripts require shell interaction. In those cases debugpy defers to the client and expects the latter to process the "runInTerminal" request in a way that ensures that environment is properly activated. I don't know if Vimspector supports it, though. The other option is always to activate the environment yourself and then launch Vimspector from it, so that it is inherited for all child processes including debugpy and your own code.

[ubaldot]

You can specify the path to Python interpreter to use to launch your code in your debug config like so:

"python": ".../bin/python3"

If you point it at the Python binary/symlink that is under Scripts in the env, it should take care of environment activation for regular venvs.

I tried it and actually I hit the wall myself :D

For Conda this is not sufficient, because its activation scripts require shell interaction. In those cases debugpy defers to the client and expects the latter to process the "runInTerminal" request in a way that ensures that environment is properly activated. I don't know if Vimspector supports it, though. The other option is always to activate the environment yourself and then launch Vimspector from it, so that it is inherited for all child processes including debugpy and your own code.

Exactly! In reality vimspector is a vim plugin, i.e. the main program is vim. I run it from the correct venv and I also add conda activate the_right_env in my .zshrc so if a new terminal is instantiated internally by vim/vimspector it should start in the correct environment.

Yes, it seems that no environments are activated at all, given that numpy is picked from /Users/ubaldot/Library/Python/3.9/lib/python/site-packages/.

However, note that vimspector is a sort of wrapper around vscode DAP, so if something is available in vscode DAP is also available at vimspector. I'll try to set "runInTerminal" : true.

[int19h]

DAP is a protocol, and as far as I know, Vimspector has its own implementation of it, separate from VSCode one (but I may be wrong; @puremourning should be able to clarify).

"runInTerminal" is a request that the debug adapter can send to the client to allow the client to control spawning the debuggee - this used in VSCode to enable the workflow where the debuggee spawns inside its own terminal (hence the name). It is used by debugpy in lieu of spawning the debuggee directly if you set "console":"integratedTerminal" or "console":"externalTerminal". But it will only work if Vimspector implements it, and even then it would help with conda only if that request is handled in a way that ensures that the shell in which debuggee is spawned is activated first.

Another thing that you might try is to use conda run - n ... python via "python" / "pythonArgs". This didn't work last I've tried it because conda run didn't do stdin/out redirection properly, but that has been a long time ago and IIRC Conda improved this scenario since then.