Virtualenv/Conda environment not activated

[macdems]

Contrary to Python extension's Test View, this test adapter does not activate virtual environment (neither for discovery nor for the tests). Consider the following run_test.py file:

import unittest
import os

class TestEnvironment(unittest.TestCase):
    def test_env(self):
        self.assertTrue(os.environ.get('VIRTUAL_ENV') is not None or
                        os.environ.get('CONDA_DEFAULT_ENV') is not None)

If you run in in either virtualenv or conda environment it should pass. Indeed Python extension's Test View does pass it. However, the same test under the Python Test Adapter fails.

The correct behavior would be to activate the current environment before the discovery and the tests.

[petercorke]

I'm having the same issue. I get ModuleNotFoundError when the tests run, but that module is present in the conda environment that I have my interpreter set to. All the tests in the sidebar have the /!\ symbol, and I'm not seeing any code lens when I open any of the tests.

The adaptor log shows the correct path to the environment and the tests

2020-12-29T02:40:54.659Z INFO unittest at 'robotics-toolbox-python': Discovering tests using python path "/HOME/opt/miniconda3/envs/dev/bin/python" in /HOME/code/robotics-toolbox-python with pattern test*.py and start directory /HOME/code/robotics-toolbox-python/tests

[kondratyev-nv]

@petercorke Can you please share your configuration? And what exact error are you seeing? Do your tests work correctly when running from command line?

Steps I've done to reproduce your error.

1. Installed conda
2. Added "python.pythonPath": "~/miniconda3/bin/python" in VSCode workspace settings
3. Tried to discover tests - Got ModuleNotFoundError: No module named 'numpy' error
4. Run python3 -m pip install . from within conda environment
5. Tried to discover tests - No errors this time, tests are discovered and successfully executed.

[kondratyev-nv]

@macdems Thank you for the issue and sorry for the late reply. Indeed, I can confirm that the virtual environment is not activated during test discovery and execution. However, from my experience with virtual env I haven't seen any issues with that. I believe I'm not that familiar with conda or virtual env, do you know of any side-effects of not activating the environment (except for environment variables of course)?

Meanwhile, I can suggest using a script to activate it. For example, create venv_pytest.sh file in the workspace with the following content

#!/bin/sh

# Activate environment
source .venv/bin/activate

# Just to make sure which Python is running
which python3 

# Simulate pytest executioin
python -m pytest "$@"

And use it as a pytest executable by modifying workspace settings

{
    "python.testing.pytestEnabled": true,
    "python.testing.pytestPath": "${workspaceFolder}/venv_pytest.sh"
}

[petercorke]

The images I included in my reply didn't show, please see this PDF version

[macdems]

@macdems Thank you for the issue and sorry for the late reply. Indeed, I can confirm that the virtual environment is not activated during test discovery and execution. However, from my experience with virtual env I haven't seen any issues with that. I believe I'm not that familiar with conda or virtual env, do you know of any side-effects of not activating the environment (except for environment variables of course)?

The issue is that the packages installed in the virtualenv (and not in global Python if one exists) are not discovered.

Python extension's Test View does activate environment, which is a correct behavior. Python Test Explorer also should (using the same command that is used e.g. for activating the environment in a terminal).

Anyway, thanks for the script. It seems a working workaround, but please try to make it unnecessary...

[kondratyev-nv]

@macdems That's weird because packages definitely should be discovered and that part works fine for me. Can you please make sure that the right interpreter is called during test discovery and execution? You can find the logging output by selecting Python Test Adapter Log in the Output section. It should look similar to the following logs

2020-12-30T09:29:20.555Z INFO pytest at '<workspace>': Using auto-detected pythonPath <path to conda>/bin/python
...
2020-12-30T09:29:20.558Z INFO pytest at ''<workspace>': Discovering tests using python path '<path to conda>/bin/python' in <workspace path>
2020-12-30T09:29:20.561Z INFO pytest at ''<workspace>': Running pytest with arguments: --collect-only
2020-12-30T09:29:20.562Z INFO pytest at ''<workspace>': Running pytest as a Python module
...

In case it's incorrect, you should be able to change the interpreter by clicking on the current one in the bottom panel of VSCode or by setting python.pythonPath to the path to your interpreter from virtual env in settings.

As a side note. I've taken a look at the activate script for venv. It seems that the script is doing two things basically - setting VIRTUAL_ENV and prepending PATH with virtual env bin folder. As Python Test Explorer is running executables to run and discover tests, in most cases setting "python.pythonPath" to an absolute path is preferred, this way modified PATH should not be a huge issue.

[petercorke]

This is what's in the log

2020-12-30T11:12:10.414Z INFO unittest at 'robotics-toolbox-python': Reading configuration for workspace robotics-toolbox-python
2020-12-30T11:12:10.416Z  DBG unittest at 'robotics-toolbox-python': usingNewInterpreterStorage feature flag is 'true'
2020-12-30T11:12:10.416Z INFO pytest at 'robotics-toolbox-python': Reading configuration for workspace robotics-toolbox-python
2020-12-30T11:12:10.417Z  DBG pytest at 'robotics-toolbox-python': usingNewInterpreterStorage feature flag is 'true'
2020-12-30T11:12:10.419Z INFO unittest at 'robotics-toolbox-python': Using auto-detected pythonPath /Users/corkep/opt/miniconda3/envs/dev/bin/python
2020-12-30T11:12:10.419Z INFO pytest at 'robotics-toolbox-python': Using auto-detected pythonPath /Users/corkep/opt/miniconda3/envs/dev/bin/python
2020-12-30T11:12:10.420Z  DBG unittest at 'robotics-toolbox-python': Sending autorun event
2020-12-30T11:12:10.420Z  DBG pytest at 'robotics-toolbox-python': Sending autorun event

the interpreter path is correct.

[macdems]

Steps to reproduce the problem (in Windows):

1. Install Anaconda. Do not add Python to the system PATH (this is a default installer option).

2. Create a following file run_test.py:

   import unittest
   
   class TestConda(unittest.TestCase):
   
       def test_import_numpy(self):
           import numpy
   

3. Setup e.g. pytest and run the above test.

Under Python's extension Test View the test runs. Under Python Test explorer it fails with:

ImportError: DLL load failed while importing _multiarray_umath: The specified module could not be found.

It seems that the Python part of the numpy is found and imported, however, the binary extension does not...

[petercorke]

I'm running on a Mac but also use numpy. Hard to understand how the import could get the python part but not the binary part.

[macdems]

I'm running on a Mac but also use numpy. Hard to understand how the import could get the python part but not the binary part.

Yes, it is hard to understand, but the problem exists, nonetheless.

[kaftand]

I found a workaround for my particular situation. Open cmd, navigate to the folder of your project. Run conda activate <env-name>. Then run code .

[quancs]

I found a workaround for my particular situation. Open cmd, navigate to the folder of your project. Run conda activate <env-name>. Then run code .

Thank you. It works.