Skip to content
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

Cannot discover tests anymore, python executable not used #22618

Closed
johansmolinski opened this issue Dec 10, 2023 · 23 comments
Closed

Cannot discover tests anymore, python executable not used #22618

johansmolinski opened this issue Dec 10, 2023 · 23 comments
Assignees
Labels
area-testing info-needed Issue requires more information from poster triage-needed Needs assignment to the proper sub-team

Comments

@johansmolinski
Copy link

Type: Bug

Behaviour

Expected vs. Actual

Expected: Clicking the tests icon should discover tests.
Actual: No tests have been found in this workspace yet.

Steps to reproduce:

  1. Load a project previously having tests discovered.
  2. Click the Tests icon.

Diagnostic data

  • Python version (& distribution if applicable, e.g. Anaconda): 3.11.6
  • 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 (ViewOutput, change the drop-down the upper-right of the Output panel to Python)

python /Users/johan/.vscode/extensions/ms-python.python-2023.22.0/pythonFiles/unittestadapter/discovery.py --udiscovery -v -s ./src -p test_*.py

and if I run that myself in the terminal, I get:

Error[vscode-unittest]: TEST_PORT is not set.  TEST_UUID =  None
Error: no uuid provided or parsed.
Error sending response: [Errno 61] Connection refused
Request data: Content-Length: 42
Content-Type: application/json
Request-uuid: 

{"command_type": "discovery", "eot": true}

User Settings


languageServer: "Pylance"

testing
• pytestArgs: "<placeholder>"
• unittestArgs: "<placeholder>"
• unittestEnabled: true

Extension version: 2023.22.0
VS Code version: Code 1.85.0 (Universal) (af28b32d7e553898b2a91af498b1fb666fdebe0c, 2023-12-06T18:18:04.614Z)
OS version: Darwin arm64 23.1.0
Modes:

System Info
Item Value
CPUs Apple M1 Max (10 x 24)
GPU Status 2d_canvas: enabled
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
Load (avg) 5, 5, 6
Memory (System) 64.00GB (0.05GB free)
Process Argv . --crash-reporter-id f7b7518c-4fd8-4a0b-b95d-1c10ff2f756b
Screen Reader no
VM 0%
A/B Experiments
vsliv368:30146709
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vstes627:30244334
vslsvsres303:30308271
vserr242:30382549
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscod805:30301674
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593cf:30376535
pythonvs932:30410667
py29gd2263:30899288
vscaat:30438848
vsclangdc:30486549
c4g48928:30535728
dsvsc012cf:30540253
azure-dev_surveyone:30548225
2e4cg342:30602488
89544117:30613380
2i9eh265:30646982
showlangstatbar:30737416
962ge761:30917236
fixshowwlkth:30771522
showindicator:30805244
pythongtdpath:30769146
i26e3531:30792625
welcomedialogc:30910334
pythonnosmt12:30797651
pythonidxpt:30866567
pythonnoceb:30805159
asynctok:30898717
dsvsc013:30795093
dsvsc014:30804076
dsvsc015:30845448
pythontestfixt:30902429
pyreplss1:30897532
pythonmypyd1:30879173
pythoncet0:30885854
pythontbext0:30879054
accentitlementsc:30887149
dsvsc016:30899300
dsvsc017:30899301
dsvsc018:30899302
aa_t_chat:30882232
dsvsc019:30917259

@github-actions github-actions bot added the triage-needed Needs assignment to the proper sub-team label Dec 10, 2023
@kristiandupont
Copy link

I don't know if this is the same issue, but I get this output:

2023-12-11 09:28:38.822 [error] Error discovering pytest tests:
 Error: spawn /Users/kristiandupont/repositories/[redacted]/venv EACCES
    at Process.ChildProcess._handle.onexit (node:internal/child_process:283:19)
    at onErrorNT (node:internal/child_process:476:16)
    at processTicksAndRejections (node:internal/process/task_queues:82:21) {
  errno: -13,
  code: 'EACCES',
  syscall: 'spawn /Users/kristiandupont/repositories/[redacted]/venv',
  path: '/Users/kristiandupont/repositories/[redacted]/venv',
  spawnargs: [
    '/Users/kristiandupont/.vscode/extensions/ms-python.python-2023.22.0/pythonFiles/testing_tools/run_adapter.py',
    'discover',
    'pytest',
    '--',
    '--rootdir',
    '/Users/kristiandupont/repositories/[redacted]',
    '-s',
    '--cache-clear',
    'api/tests/'
  ]
}

This started happening right after I upgraded VSCode today. I wonder if it introduced stricter roles for subprocesses?

@johansmolinski
Copy link
Author

My issue does not seem to be related to access rights.

Some updates. I rebooted my computer, because why not, and the issue changed a bit. Now at least it tries to scan for tests, but finds 0. However, now the tests can be run individually from the editor (the run test arrow pops up at the test definition code). By the way, from the terminal I can still run the test suite using python -m unittest.

@AndreasHaure
Copy link

I don't know if this is the same issue, but I get this output:

2023-12-11 09:28:38.822 [error] Error discovering pytest tests:
 Error: spawn /Users/kristiandupont/repositories/[redacted]/venv EACCES
    at Process.ChildProcess._handle.onexit (node:internal/child_process:283:19)
    at onErrorNT (node:internal/child_process:476:16)
    at processTicksAndRejections (node:internal/process/task_queues:82:21) {
  errno: -13,
  code: 'EACCES',
  syscall: 'spawn /Users/kristiandupont/repositories/[redacted]/venv',
  path: '/Users/kristiandupont/repositories/[redacted]/venv',
  spawnargs: [
    '/Users/kristiandupont/.vscode/extensions/ms-python.python-2023.22.0/pythonFiles/testing_tools/run_adapter.py',
    'discover',
    'pytest',
    '--',
    '--rootdir',
    '/Users/kristiandupont/repositories/[redacted]',
    '-s',
    '--cache-clear',
    'api/tests/'
  ]
}

This started happening right after I upgraded VSCode today. I wonder if it introduced stricter roles for subprocesses?

Have encountered the same exact issue after the latest update of vscode. It looks like the discovery command that vscode is executing is wrong. From the terminal I can see it is executing

~/source/[redacted]/.venv ~/.vscode/extensions/ms-python.python-2023.22.0/pythonFiles/testing_tools/run_adapter.py discover pytest -- --rootdir ~/source/[redacted] -s --cache-clear tests

However it works if I change that to the following and run it manually in my terminal:

~/source/[redacted]/.venv/bin/python ~/.vscode/extensions/ms-python.python-2023.22.0/pythonFiles/testing_tools/run_adapter.py discover pytest -- --rootdir ~/source/[redacted] -s --cache-clear tests

@eff917
Copy link

eff917 commented Dec 11, 2023

Happened to me too, downgrading Python extension to 2023.20 solves the issue, so bug is in 2023.22 extension version.

OS: Arch linux
VSCode: 1.85.0
Python : 3.12.0 with poetry venv
Pytest: 7.4.3

Python extensions tested:

  • 2023.22 - no discovery (pytest works in console)
  • 2023.20 - works
  • 2023.18 - works

edit: If we can provide any logs, please let us know

@eleanorjboyd eleanorjboyd self-assigned this Dec 11, 2023
@danibishop
Copy link

Can confirm the same behaviour that @eff917 mentions. Downgrading is the easiest way to mitigate, it seems.

@bricker
Copy link

bricker commented Dec 12, 2023

I had a similar problem today with pytest. No errors in the Output console though. It just said this:

[info] Discover tests for workspace name: [...]
[info] Running discovery for pytest using the new test adapter.

But nothing happened.

To work around it, I disabled the new test adapter experiment by adding this to my VSCode user settings:

"python.experiments.optOutFrom": ["pythonTestAdapter"]

After adding this (and restarting VSCode), Python tests were discovered correctly. And, I can't explain why, but I went back and removed that setting and test discovery is now working with the new test adapter. 🤷

  • vscode-python version: 2023.22.0
  • VSCode version: 1.84.2 (via apt)
  • pytest version: 7.4.3
  • python version: 3.12.0
  • OS: Ubuntu 23.04

@nmost
Copy link

nmost commented Dec 12, 2023

This is also happening for me on Sonoma 14.2. Downgrading the Extension to 2023.20 fixed the issue

@M3ssman
Copy link

M3ssman commented Dec 12, 2023

Editing python.experiments.optOutFrom doesn't work as suggested (Ubuntu 20.04 LTS, Python 3.8.13, /ms-python.python-2023.22.0) but produces the output

2023-12-12 07:37:58.774 [info] Starting Pylance language server.
2023-12-12 07:38:03.589 [info] Discover tests for workspace name: ulb-it-migration - uri: /home/hartwig/Projekte/ulb-it-migration
2023-12-12 07:38:03.633 [info] > . ./venv/bin/activate && echo 'e8b39361-0157-4923-80e1-22d70d46dee6' && python ~/.vscode/extensions/ms-python.python-2023.22.0/pythonFiles/printEnvVariables.py
2023-12-12 07:38:03.633 [info] shell: bash
2023-12-12 07:38:03.682 [info] > ./venv ~/.vscode/extensions/ms-python.python-2023.22.0/pythonFiles/testing_tools/run_adapter.py discover pytest -- --rootdir . -s --cache-clear tests
2023-12-12 07:38:03.682 [info] cwd: .
2023-12-12 07:38:03.693 [error] Error discovering pytest tests:
 [Error: spawn /home/hartwig/Projekte/ulb-it-migration/venv EACCES
	at ChildProcess._handle.onexit (node:internal/child_process:283:19)
	at onErrorNT (node:internal/child_process:476:16)
	at process.processTicksAndRejections (node:internal/process/task_queues:82:21)] {
  errno: -13,
  code: 'EACCES',
  syscall: 'spawn /home/hartwig/Projekte/ulb-it-migration/venv',
  path: '/home/hartwig/Projekte/ulb-it-migration/venv',
  spawnargs: [
    '/home/hartwig/.vscode/extensions/ms-python.python-2023.22.0/pythonFiles/testing_tools/run_adapter.py',
    'discover',
    'pytest',
    '--',
    '--rootdir',
    '/home/hartwig/Projekte/ulb-it-migration',
    '-s',
    '--cache-clear',
    'tests'
  ]
}

@danielWagnerr
Copy link

Same problem as @kristiandupont here

@eleanorjboyd
Copy link
Member

Hello everyone, sorry for the delay and lets figure out the problem here. It seems that "python.experiments.optOutFrom": ["pythonTestAdapter"] this was a fix for some but not all so given this we have two different issues, one which is impacted by the experiment being on and one which does not depend on the experiment.

@johansmolinski with Error[vscode-unittest]: TEST_PORT is not set. TEST_UUID = None Error: no uuid provided or parsed. What happens is we set an env var to store the value of the UUID and PORT for testing and spin up a subprocess with these env vars to pass this information. Can you check to see if you override or clear environment variables during testing?

@kristiandupont, it seems you are running the old discovery, can you please try and run the new testing experiment. Your logs reference /pythonFiles/testing_tools/run_adapter.py which is a file only used in the old code. You could try opting into the experiment explicitly ("python.experiments.optInto": ["pythonTestAdapter"]) but everyone should have the experiment so I am not sure why you are still seeing the old code. I would check to see if you are opted out from all experiments in your workspace or user settings.

@johansmolinski, can you include logs from this run "Now at least it tries to scan for tests, but finds 0". Please set log level to trace via the command palette.

@AndreasHaure and @M3ssman same as @kristiandupont, try to switch to new experiment.

@eff917, @nmost, and @danibishop if you could provide logs that would be great, if you could also set log level to trace via the command palette.

@bricker, interesting a re-start worked, let me know if you see this behavior pop up again.

Thanks everyone for engaging on this issue!

@github-actions github-actions bot added the info-needed Issue requires more information from poster label Dec 12, 2023
@smoy
Copy link

smoy commented Dec 12, 2023

I reproduce the same symptom and I found what mades a difference for me is how I open vscode for my project. If I open VSCode first, and then select the pre-existing virtualenv, I can make test discovery to work. However, my typical using the /usr/local/bin/code (already in my path, so i just code .) code ., the test discovery will consistent not work.

Like others, if i revert to earlier vscode python extension 2023.20.0, test discovery works normally.

More specifically. before I use code ., i am already inside a virtualenv, i think this affects the environment detection. If i use code . outside of an already active virtual environment, I am able see test discovery normally.

@eleanorjboyd
Copy link
Member

Hello everyone, I am able to repro the issue and am in the process of narrowing down what commit in release 2023.22.0 is causing the issue. I will send updates in this issue.

The issue is the wrong path is put for the python executable:
expected ./.venv/bin/python -m pytest -p vscode_pytest --collect-only . (which works)
actual ./.venv -m pytest -p vscode_pytest --collect-only . (which doesn't work)

@eleanorjboyd
Copy link
Member

I am only able to repro with @smoy steps using code .. What are other environment configurations that people have which are leading to this bug? I am interested in where your executable you are trying to use is and how you loaded vscode to then start work on your project that might have caused the executable to not be selected correctly. Looking for an additional repro and will continue to explore the problem.

@eleanorjboyd eleanorjboyd changed the title Cannot discover tests anymore Cannot discover tests anymore, python executable not used Dec 12, 2023
@stuartmaxwell
Copy link

So glad I found this thread! Been struggling with this for the last few hours. As others have commented, if I launch VS Code from the terminal using code . it is unable to discover tests. But if I manually select the Python interpreter (actually, "reselect" is the correct term since it appears that VS Code is already using the correct interpreter), then test discovery works fine. Also, if I launch a new instance of VS Code, then open the project folder from the File menu, then test discovery works as expected first time. Hope that helps.

@karrtikr karrtikr self-assigned this Dec 12, 2023
karrtikr pushed a commit that referenced this issue Dec 12, 2023
…g" (#22638)

Reverts #22413
#22618

Turns out we still need this code for old deprecated APIs that we
expose, one of which is used in testing.
@karrtikr
Copy link

Hi everyone, we've deployed a fix to the pre-release version. Please give it a try and let us know if it helps.

image

@smoy
Copy link

smoy commented Dec 13, 2023

@karrtikr I can confirm switching to pre-release version resolve the test discovery issue.

@github-actions github-actions bot removed the info-needed Issue requires more information from poster label Dec 13, 2023
eleanorjboyd pushed a commit to eleanorjboyd/vscode-python that referenced this issue Dec 13, 2023
…g" (microsoft#22638)

Reverts microsoft#22413
microsoft#22618

Turns out we still need this code for old deprecated APIs that we
expose, one of which is used in testing.
@dnwillia
Copy link

I am only able to repro with @smoy steps using code .. What are other environment configurations that people have which are leading to this bug? I am interested in where your executable you are trying to use is and how you loaded vscode to then start work on your project that might have caused the executable to not be selected correctly. Looking for an additional repro and will continue to explore the problem.

@eleanorjboyd I have the issues described here and I am doing what you say. cd into my project directory, activate my virtual environment and then type code . on the command line, but the same thing happens if I start VS code from the Applications folder and pick the project directory. In the latter case when I hit F1 and "Select Python Interpreter" I can see that it has automatically selected "./venv" rather than "./venv/bin/python" and when I update it to the latter it seems to be working. This is with 2023.22.0.

@laipz8200
Copy link

Hi everyone, we've deployed a fix to the pre-release version. Please give it a try and let us know if it helps.

image

This update solved my problem.

@stuartmaxwell
Copy link

Hi everyone, we've deployed a fix to the pre-release version. Please give it a try and let us know if it helps.

image

This fixed the issue for me. thanks.

@royby-cyberark
Copy link

royby-cyberark commented Dec 13, 2023

@stuartmaxwell - works for me. The "Testing" explorer was first still at the "No tests were found...", so I thought it didn't work but after a few seconds it loaded the tests.

thanks!

@firatkizilirmakk
Copy link

Hi everyone, we've deployed a fix to the pre-release version. Please give it a try and let us know if it helps.

image

this worked for me as well.

thanks.

karthiknadig pushed a commit that referenced this issue Dec 13, 2023
…g" (#22638)

Reverts #22413
#22618

Turns out we still need this code for old deprecated APIs that we
expose, one of which is used in testing.
@eff917
Copy link

eff917 commented Dec 13, 2023

Also confirmed, ms-python.python-2023.23.13471011 solved discovery problems.

@eleanorjboyd
Copy link
Member

closing as the point release contains the fix to this issue. Please comment if you are still experiencing problems even on the point release. Thanks

@github-actions github-actions bot added the info-needed Issue requires more information from poster label Dec 14, 2023
@eleanorjboyd eleanorjboyd added this to the December / January 2024 milestone Dec 14, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jan 14, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-testing info-needed Issue requires more information from poster triage-needed Needs assignment to the proper sub-team
Projects
None yet
Development

No branches or pull requests