Virtual environment is not fully activated when running tests in non-debug mode #22630
Comments
github-actions
bot
added
the
triage-needed
|
Related to #4300, but that one seemingly covers debugging rather than regular runs. |
|
Hi! Could you try switching from the python extension version |
|
Hi @eleanorjboyd, thank you for taking a look. I tried out version |
github-actions
bot
removed
the
info-needed
|
Thanks for checking, ill look into this further |
|
I could reproduce the bug (just note that you need to install I have a similar issue with unit tests that utilize a local spark cluster. The error message is different but the behavior of the bug is exactly the same. For my case I inspected the environment that is setup when debugging a test vs running a test. It turned out that you can solve the issue by putting the current env into the PATH variable before running the subprocess (or before creating a local pyspark session as in my case): import subprocess
def test_main():
os.environ["PATH"] = os.getcwd() + "/.testvenv/bin:" + os.environ["PATH"]
result = subprocess.run(("./main_program_under_test",))
assert result.returncode == 0Maybe this hint helps to find a general solution for this bug. |
|
Hi @eleanorjboyd - I am experiencing the same problem. Maybe this additional diagnostic will help. It seems that when executing tests via If the environment is activated, these directories are prepended to the and there are other environment variables as well, for example, However, when running under When doing a normal "Run Python File", everything seems to be working correctly. Below are two different outputs - one from running just a script and the other running You can compare the two environments and how which("python") behaves. I have highlighted a couple of key differences with "---->". I also note a couple of other things:
For what it's worth, we are also working in a pyspark environment and what matters is the Is there anything I should be doing differently? Thanks pytest with -- -- Run Python Program -- -- |
|
Hi @eleanorjboyd - I just figured out that it does work when debugging Also, in case it helps, there's slightly different behaviour in how Here's what I have in my Here's all four cases, along with how environment variables are set Run Python File: virtual environment is activated Debug Python File: virtual environment is activated Run Test virtual environment is not activated Debug Test virtual environment is activated |
|
Hi @binderjoe. This is blocking users of our Databricks Extension as well, because we install some databricks packages to their virtual envs, which we need activated properly for functions such as "Run Python File in Integrated Terminal", but with the Databricks features enabled. Is it possible to prioritise this issue? |
|
With my Python core developer hat on, I want to say that assuming the virtual environment is activated is a bit dangerous as it's actually not necessary for the interpreter to work correctly. The shell scripts are considered a nice-to-have developer feature to make working in the shell easier and not meant to be required for code to function. As such, users can and do launch interpreters in virtual environments w/o ever activating them. And this isn't even covering the case of when people use a shell for which there aren't any activation scripts available. If you need to know what Python interpreter you are using, |
github-actions
bot
added
the
info-needed
|
@brettcannon agreed. But the current behaviour is, the terminal is showing that the environment is activated (the python extension changes the PS1 I believe?), but the environment is not actually activated. Anyway, seems like a combination of vscode update (to 1.86.2) and the latest extension version (v2024.2.0) seems to have fixed the issue for me now atleast. |
|
Hi Brett - just to add to this, it's not so much the running Python execution environment that needs the activation script, it's the PATH for things that are called by Python or in a terminal. Two examples
Agreed on the other environment variables, but the PATH shouldn't be misleading thanks for looking |
This actually has nothing to do w/ how we run tests. Terminal activation occurs using VS Code APIs and only when you open a terminal (and any prompt issues are due to your shell's design or how some start-up script overrides what our activation does because of how early it occurs). Testing normally occurs in a subprocess and not the terminal (hence the "non-debug mode" in the title of this issue). So the way to get an "activated" subprocess is to either execute using a shell subprocess (which is itself problematic as that requires we do shell escaping and that's really hard as escaping rules are not well documented, vary from shell to shell, etc.), or we calculate what environment variable changes are required and then apply those changes (which is costly for e.g. conda). Chances are we used to do the latter and missed that detail in the testing rewrite.
Another FYI w/ my core dev hat on, I would advise against running pip directly, or at least use it's |
|
thanks, Brett. Just in case it helps diagnostically, I did notice that there are four different behaviors, which are different when running with and without debug. see above. again, thanks for looking. Kevin |
|
In my tests I test that templated files passes Ruff check after rendering. I used to have: import subprocess
import pytest
def test_passes_ruff_check(rendered_project: Path):
try:
subprocess.check_output(["ruff", "check", "."], cwd=rendered_project)
except subprocess.CalledProcessError as exc:
pytest.fail(exc.output)After the This can be "fixed" by changing the subprocess call to: subprocess.check_output([sys.executable, "-m", "ruff", "check", "."], cwd=rendered_project) |
|
@LKajan thank you for the clear steps- I will investigate. |
|
Because we have not heard back with the information we requested, we are closing this issue for now. If you are able to provide the info later on, then we will be happy to re-open this issue to pick up where we left off. Happy Coding! |
|
Because we have not heard back with the information we requested, we are closing this issue for now. If you are able to provide the info later on, then we will be happy to re-open this issue to pick up where we left off. Happy Coding! |
karthiknadig
added
the
bug
Type: Bug
Behaviour
Expected vs. Actual
Expected: When I run discovered pytests in non-debug mode via the "testing" tab, it behaves as though I ran pytest with the virtual environment configured for the workspace activated.
Actual: I have a particular test which uses subprocess.run to spawn another script which executes with the Python interpreter using a shebang (#!/usr/bin/env python3). When I run this test in my shell with the Python virtual environment active, the shebang executable resolves to the binary for the active environment, the desired behaviour. However, when I run the same test using the "testing" feature in VSCode, the executable is resolved to the system Python binary and the test fails as a consequence.
It is notable that this does not occur when I run the test in debug mode, there it works properly.
Steps to reproduce:
See the sample repository with steps to reproduce in the README: https://github.com/KyleRAnderson/vscode-python-bug-22630.
Diagnostic data
python.languageServersetting: PylanceOutput for
Pythonin theOutputpanel (View→Output, change the drop-down the upper-right of theOutputpanel toPython)User Settings
Extension version: 2023.22.0
VS Code version: Code 1.85.0 (af28b32d7e553898b2a91af498b1fb666fdebe0c, 2023-12-06T20:48:09.019Z)
OS version: Windows_NT x64 10.0.19045
Modes:
Remote OS version: Linux x64 5.15.133.1-microsoft-standard-WSL2
Remote OS version: Linux x64 5.15.133.1-microsoft-standard-WSL2
Connection to 'wsl+ubuntu' could not be established
System Info
canvas_oop_rasterization: enabled_on
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
video_decode: enabled
video_encode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled
webgpu: enabled
Connection to 'wsl+ubuntu' could not be established
A/B Experiments
The text was updated successfully, but these errors were encountered: