vscode-python: Pytest discovery fails on RHEL8 due to symlink

Type: Bug

Behaviour

Expected vs. Actual

My company controlled workstation is being upgraded from CentOS7 to RHEL8 and I’ve been beta testing the RHEL8 workstation this week. I’m using the Remote SSH plugin to open Python projects on the Linux workstation from a Windows 10 desktop.

On CentOS7, VSCode has no problems discovering and running my test suites in pytest. On RHEL8, it shows all the containing modules but no tests in the tree beneath them. I’ve tried with both the release channel and insiders versions of VSCode (with All expriments enabled and the test server started for insiders) and get the same result.

Steps to reproduce:

Open Python project with pytest tests
Switch to Test Explorer
Tests are not discovered; no errors or anything beyond “info” messages in logs, even with python.analysis.logLevel = TRACE.
Refresh Tests; same behavior

Diagnostic data

Python version (& distribution if applicable, e.g. Anaconda): 3.9.16
Type of virtual environment used (e.g. conda, venv, virtualenv, etc.): Venv
Value of the python.languageServer setting: Default

Output for Python in the Output panel

2023-06-06 14:06:31.749 [info] Experiment 'pythonPromptNewFormatterExt' is active
2023-06-06 14:06:31.749 [info] Experiment 'pythonPromptNewToolsExt' is active
2023-06-06 14:06:31.749 [info] Test server listening.
2023-06-06 14:06:31.749 [info] Python interpreter path: ./.venv/bin/python
2023-06-06 14:06:40.405 [info] Starting Pylance language server.
2023-06-06 14:22:46.295 [info] > . ./.venv/bin/activate && echo 'e8b39361-0157-4923-80e1-22d70d46dee6' && python /alt/.vscode-server/extensions/ms-python.python-2023.8.0/pythonFiles/printEnvVariables.py
2023-06-06 14:22:46.295 [info] shell: bash
2023-06-06 14:22:46.336 [info] > ./.venv/bin/python /alt/.vscode-server/extensions/ms-python.python-2023.8.0/pythonFiles/testing_tools/run_adapter.py discover pytest -- --rootdir . -s --cache-clear
2023-06-06 14:22:46.336 [info] cwd: .

User Settings


languageServer: "Pylance"

linting
• flake8Args: "<placeholder>"
• flake8Enabled: true

formatting
• provider: "black"

testing
• cwd: "<placeholder>"
• pytestEnabled: true

terminal
• activateEnvironment: false

Extension version: 2023.8.0 VS Code version: Code 1.78.2 (b3e4e68a0bc097f0ae7907b217c1119af9e03435, 2023-05-10T14:39:26.248Z) OS version: Windows_NT x64 10.0.19044 Modes: Sandboxed: Yes Remote OS version: Linux x64 4.18.0-425.19.2.el8_7.x86_64 Remote OS version: Linux x64 3.10.0-1160.88.1.el7.x86_64 Remote OS version: Linux x64 4.18.0-425.19.2.el8_7.x86_64 Remote OS version: Linux x64 4.18.0-425.19.2.el8_7.x86_64

A/B Experiments

vsliv368cf:30146710
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
vserr242cf:30382550
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vsdfh931:30280409
vshan820:30294714
vstes263:30335439
vscod805:30301674
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
cmake_vspar411:30581797
vsaa593:30376534
pythonvs932:30410667
cppdebug:30492333
vscaat:30438848
vsclangdf:30486550
c4g48928:30535728
dsvsc012cf:30540253
pynewext54:30695312
azure-dev_surveyone:30548225
2e4cg342:30602488
pyind779:30671433
89544117:30613380
pythonsymbol12:30671437
showlangstatbar:30737416
vsctsb:30748421
pythonms35:30701012
03d35959:30757346
pythonfmttext:30731395
pythoncmv:30756943
fixshowwlkth:30730052
hidesbindicator:30730055
pythongtdpathcf:30739705
pythonnosmt12:30757131

About this issue

Original URL
State: closed
Created a year ago
Reactions: 1
Comments: 38 (15 by maintainers)

Most upvoted comments

Spent over an hour trying and giving up solving the tests being discovered but not being run no matter what i did, no logs anywhere giving any hints, until because of mrburrito i tried just opening code directly from the same folder (code . instead of code coding/org/project) and now it just works. Thank you 😭

MartinCura on Aug 5, 2023

#9347 appears to be similar. It looked like that was more about starting python from a symlink though it seems that the conversation steered towards opening projects with path substitution at the end (e.g. from ~/source/project instead of /home/user/source/project or, in WSL, c:\Users\user\source\project) rather than opening a project from a symlink. There are definitely other related issues that stem from opening the code from a symlinked location, which is how I stumbled on the solution. #19864 is the one that led me to the solution, though that is already marked closed.

mrburrito on Jul 12, 2023