-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Activate environment before debugging tests #4300
Comments
@mbunse Does it work for you when no run the code without debugging? |
Yes. Clicking "Run Test" works as expected. |
I can reproduce this locally on Windows 10, with the following repo sample: 4300_conda_debug_tests_with_numpy.zip
Resulting screenOutput :: Python Test
Debug Console
Developer Tools WindowClick to expand...
|
We have a similar issue that during debugging of a script the conda environment is not activated before the script is started in debug mode. Similar to #2862 but in It works if the debugging is started a second time using the same internal terminal. Then the conda environment is activated before running the script in debug mode. I can open a new issue but they all seem to have a similar cause |
Does this have to do with the below numpy issue? |
I see the same error (on a fresh install of everything as well). This is not likely due to the numpy error. |
Please could you provide the following info:
|
I have the same issue: python 2019.4.1.11881,conda 4.5.11
errors:
|
@Zhi-Liu Please could you check your |
I am able to reproduce this with a completely empty workspace and a brand new fresh conda environment.
environment.yml : name: vscode-pytest-conda
channels:
- defaults
dependencies:
- python==3.7.3
- pytest==4.5.0
- numpy==1.16.3 tests/conftest.py : import numpy Python Test Log (after trying to collect tests)
What I understand is this is generally an issue of environment activation, or more specifically that environment and path variables are somehow set to resolve the wrong locations for dlls to be discovered before the the paths associated to the virtual environment. If I activate this environment from the terminal, activate the environment, start I don't see any messages or errors that are meaningful in the Developer Tools related to this. @DonJayamanne could you point me to where the environment is activated for the test collection/debugging/running, or even how I might be able to inspect the value of my PATH variable in the context of the Python extension to see how it might differ? I can try to troubleshoot from there... |
Ok so I dug a little more and tried adding this to the top of import os
print(os.environ.get("PATH")) And from this output I was able to verify that the conda environment selected in VSCode is not listed in the PATH variable as it would be if the environment were activated. So then I changed it to |
I have a similar issue, but it feels like the Python debug mechanism does not activate the relevant conda environment before running the compiler. Here's my workspace settings.json file: As for the debug configuration, I have ensured that the console used is "integratedTerminal". I was attempting to debug a Flask script. In the first debug run, I encountered the same "ImportError: DLL load failed" error, and I noticed that the conda environment is then activated.
When I ran debug again without closing the debug console, the console retained the conda environment, and is able to run the Flask script:
Is there a way to actually pre-activate the environment before running the debug? I think this may solve the issue at hand. |
HI I found that if I open a cmd window, and activate the conda enviromment from there, and then start code from within the window, opening the right folder, it actually works! |
Well, that's the definite way of activating environment prior to debugging the solution. However, I would like to 'load' the Python environment before debugging. I have even tried to create a separate task trying to load the conda environment before debugging, but I could not combine both integrated terminals together. |
Seem to fix the issue by adding "python": "${command:python.interpreterPath}" to the standard launch.json file |
I prefer this solution (with some modifications) to others. I just had to modify launch.json and use integrated terminal while debugging (the solution proposed above). I removed the python path line in the json file since selecting conda env (select interpreter) worked for me. Also I had to remove the "program" keyword for debugging pytests. With this, I had no import errors while debugging a single file or a pytest function/class. Activate environment and starting vscode from powershell worked for me but it is a hassle compared to editing launch.json and living with the integrated environment. Modified launch.json:
|
Hi everyone 👋 please try this workaround for conda until we get this fixed which requires coordination with VSCode and conda.
related #10626. This works in most cases except remote. If that doesn't work, as a temporary solution please change the setting |
What is wrong with the workaround mentioned by @niveshd ? The one you suggest needs to be doe every time we start VS Code, and if another env is wanted to be used for debugging, we need to restart VS Code, don't we? The page you suggest tells that this has no effect in Windows. Is your suggestion OS-specific? |
I was having the same problem and none of the suggested solutions above seemed to be working (Windows 10, python 3.8, VScode 1.56). I found that my issue was from the Powershell not properly activating my conda environment when I ran the script within or outside of the debugger. When I ran the script from the command prompt or imported numpy in the terminal everything worked as it should. Inside the user settings.json (not the settings.json for configuring the current interpreter found in .vscode folder) found in I believe this tells VScode to run all debugging sessions with the command prompt instead of the default powershell. Hope this helps someone else who's having the same issue. |
|
workaround I'm currently using that I haven't seen discussed: instead of invoking |
A friend of my spend several hours on his Windows machine until I pointed out to this thread here, maybe this issue shall be investigated by microsoft devs with a higher priority. At least to avoid people saying Windows is developer unfriendly ... Especially, the conda/vscode combination works on mac/linux. |
My setup followed below by workaround...
TL;DR: I launch VS Code from desktop shell which picks up global Python env by default, where VS Code will use configured venv just fine for app debugging, but not for pytest test debugging. To workaround, I launch VS Code from command prompt that has desired venv active and VS Code then uses that venv during debugging for both the app debugging (which never had an issue) and pytest test debugging (which had an issue, resolved with this workaround). No issues outside of debugging. Details... When debugging primary app with 3.9.12 venv, no issues whatsoever. If I launch with breakpoint at start of main app (not pytest test), and run the below in VS Code debugging console, I see it has selected the right python.exe from the venv. And this is my VS Code venv setting.
With the same above configuration, when I choose to debug a test under pytest, the debugger works, but when I set a breakpoint at start of test, run the same commands as above, here is what I see...
It is using the global (non-venv) Python 3.10 installation despite VS Code being set/configured for the 3.9.12 venv which works great when debugging a non-pytest app. The workaround I'm using is to activate the venv from PowerShell and launch code.cmd from the same PowerShell terminal window as follows...
After doing the above, when I hit that same breakpoint in the pytest test mentioned above, and run the same commands to find python.exe, it seems it can find it just fine...
I also checked os.getenv('PATH') and it reveals a proper path setup for that 3.9.12 venv, unlike when I check the path when debugging the pytest test while relying on VS Code alone to select the right venv. The main difference is I launched VS Code two different ways, one from the command prompt with venv setup, the other from desktop shell (Start/Menu/Code) which picks up global Python env by default and despite VS Code using the selected venv for development purposes, it fails to use the venv when debugging pytest. Debugging works great, but it's under a Python 3.10 environment which is undesired. As others reported, running a pytest worked fine... it seemed tied to debugging for some reason. |
I prefer the internal console to the integration terminal, and in order for scripts in my virtualenv to be found, I explicitly add the virtualenv's bin/ to the path: {
"version": "0.2.0",
"configurations": [
{
"name": "testing",
"type": "python",
"request": "launch",
"purpose": ["debug-test"],
"justMyCode": false
"env": { "PATH": "${workspaceFolder}/.venv/bin"}
}
]
} This prepends my virtualenv in |
Workaround for remote scenariosIn scenarios where it's not possible to launch VSCode via an activated environment, I have captured the instructions in a GIF: Here're step by step instructions for the example:
|
Haven't had success with proposed workarounds when using the Remote-SSH extension. I wouldn't mind starting in an activated environment, but @karrtikr 's instructions do not appear to effect the shell used by the test-debugger. |
Adding below key:value pair in launch.json file, fixed my problem
Then run below code in any PowerShell terminal to set the execution policy to run PowerShell code
It runs Activate.ps1 (which activates python environment) file in PowerShell debug terminal, before running the python file that has break point. |
Should be fixed in the latest stable release of Python extension, please give it a try. |
Expected behaviour
Test runs in debug mode
Actual behaviour
When "Debug Test" is selected from within the editor above a unittest the known error message from #3330 is shown
Steps to reproduce:
Logs
The text was updated successfully, but these errors were encountered: