Pytest test discovery fails due to libcudart loading message

[diricxbart]

Environment data

• VS Code version: 1.43.0
• Extension version (available under the Extensions sidebar): Python 2020.2.64397
• OS and version: Windows 10
• Python version (& distribution if applicable, e.g. Anaconda): 3.6.9
• Type of virtual environment used (N/A | venv | virtualenv | conda | ...): N/A
• Relevant/affected Python packages and their versions: pytest 5.4.1
• Relevant/affected Python-related VS Code extensions and their versions: XXX
• Jedi or Language Server? (i.e. what is "python.jediEnabled" set to; more info How to update the language server to the latest stable version #3977): Language Server
• Value of the python.languageServer setting: Microsoft

Expected behaviour

Automatic test discovery

Actual behaviour

Message: Test discovery error, please check the configuration settings for the tests.

Steps to reproduce:

1. Docker container based on this NVidia Docker base image, build server has GPU's (4x V100)
   FROM nvcr.io/nvidia/tensorflow:19.12-tf1-py3
2. A pytest where the module under test has a import tensorflow as tfstatement

Logs

Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)

> /usr/bin/python ~/.vscode-server/extensions/ms-python.python-2020.2.64397/pythonFiles/testing_tools/run_adapter.py discover pytest -- --rootdir /git/research-manifest -s --cache-clear .
cwd: /git/research-manifest

Output from Console under the Developer Tools panel (toggle Developer Tools on under Help; turn on source maps to make any tracebacks be useful by running Enable source map support for extension debugging)

Test discovery error, please check the configuration settings for the tests.
onDidChangeNotification @ notificationsAlerts.ts:40
console.ts:137 [Extension Host] Error Python Extension: 2020-03-15 20:51:37: Python Extension: displayDiscoverStatus [r [Error]: 2020-03-15 20:51:36.058657: I tensorflow/stream_executor/platform/default/dso_loader.cc:44] Successfully opened dynamic library libcudart.so.10.2	at ChildProcess.<anonymous> (/root/.vscode-server/extensions/ms-python.python-2020.2.64397/out/client/extension.js:1:455844)	at Object.onceWrapper (events.js:288:20)	at ChildProcess.emit (events.js:200:13)	at ChildProcess.EventEmitter.emit (domain.js:471:20)	at maybeClose (internal/child_process.js:1021:16)	at Process.ChildProcess._handle.onexit (internal/child_process.js:283:5)]
t.log @ console.ts:137

If I run the Python command manually:

root@3bbd644007be:/git/research-manifest# python /root/.vscode-server/extensions/ms-python.python-2020.2.64397/pythonFiles/testing_tools/run_adapter.py discover pytest -- --rootdir /git/research-manifest -s --cache-clear .
2020-03-14 07:08:49.715514: I tensorflow/stream_executor/platform/default/dso_loader.cc:44] Successfully opened dynamic library libcudart.so.10.2
[{"rootid": ".", "root": "/git/research-manifest", "parents": [{"id": "./ai", "kind": "folder", "name": "ai", "parentid": ".", "relpath": "./ai"}, {"id": "./ai/ml_serving", "kind": "folder", "name": "ml_serving", "parentid": "./ai", "relpath": "./ai/ml_serving"}, {"id": "./ai/ml_serving/test", "kind": "folder", "name": "test", "parentid": "./ai/ml_serving", "relpath": "./ai/ml_serving/test"},
...

The culprit here is the automatically generated message of libcudart loading, of coarse inside those nice list-like brackets... I think this causes the parsing of the pytest discovery output to fail.

My current workaround

As a workaround I now did the following:

• pip install pytest-env, to allow defining environment variables in the pytest.ini file
• add the TF_CPP_MIN_LOG_LEVEL environment variable in the pytest.ini file, which mutes that libcuadart message

My pytest.ini now looks like this:

[pytest]
norecursedirs = ai/public_models* .repo* BDA_tf* tools*
addopts=-s
env =
    TF_CPP_MIN_LOG_LEVEL=1

This way the libcudart message is no longer interfering with the automatic test discovery. However, it would be better if the test discovery could handle these type of interfering messages.

[karthiknadig]

Closing in favour of #6594