Hello! Can you try on our rewrite that redesigns the architecture of how teseting works? To try it yourself, add this setting to your users settings.json "python.experiments.optInto": ["pythonTestAdapter"].

You can confirm you have the rewrite enabled by setting "python.analysis.logLevel": "Trace", in your user settings then check for Experiment 'pythonTestAdapter' is active in your python logs.

If this doesn't fix your issue, please attach logs from the "python" output channel with the trace setting as decribed above.

Hi @eleanorjboyd , I followed your advice, no luck. Please see below the logs.

I am not fully sure, but conda itself is an alias in the shell, is the environment properly capturing this ? This is not my set up, this what happens when running conda init. It might be that the extension is using a different profile or not loading it properly.

which conda
conda ()
{
    \local cmd="${1-__missing__}";
    case "$cmd" in
        activate | deactivate)
            __conda_activate "$@"
        ;;
        install | update | upgrade | remove | uninstall)
            __conda_exe "$@" || \return;
            __conda_reactivate
        ;;
        *)
            __conda_exe "$@"
        ;;
    esac
}

2023-11-01 02:47:46.876 [info] Experiment 'pythonTestAdapter' is active
...
2023-11-01 02:47:57.298 [debug] Cached data exists KeyPrefix=Cache_Method_Output_S.getCondaVersion-Args=
2023-11-01 02:47:57.299 [debug] Found executable within conda env {"name":"common_env","prefix":"/export/home/anaconda/2022.10/envs/common_env"}
2023-11-01 02:47:57.310 [info] > conda run -n common_env --no-capture-output python ~/.vscode-server/extensions/ms-python.python-2023.14.0/pythonFiles/get_output_via_markers.py -m pytest -p vscode_pytest --collect-only test
2023-11-01 02:47:57.310 [info] cwd: ~/projects/dams-core
2023-11-01 02:47:57.311 [error] Error while trying to run pytest discovery, 
Error: spawn conda ENOENT


2023-11-01 02:47:57.314 [error] pytest test discovery error
 [Error: spawn conda ENOENT
	at Process.ChildProcess._handle.onexit (node:internal/child_process:283:19)
	at onErrorNT (node:internal/child_process:478:16)
	at processTicksAndRejections (node:internal/process/task_queues:83:21)] {
  errno: -2,
  code: 'ENOENT',
  syscall: 'spawn conda',
  path: 'conda',
  spawnargs: [
    'run',
    '-n',
    'common_env',
    '--no-capture-output',
    'python',
    '/home/matbouchy/.vscode-server/extensions/ms-python.python-2023.14.0/pythonFiles/get_output_via_markers.py',
    '-m',
    'pytest',
    '-p',
    'vscode_pytest',
    '--collect-only',
    'test'
  ]
}

Do you think it could be related to: #17641 (comment), thinking the conda activation might not be working as expected leading to the error.

That's definitely possible. My hunch is that when you spawn you don't source the relevant profile. Can you detail what profile you would expect to be loaded ? It needs to find a PATH for instance, and as conda is defined as an alias, it needs to source that definition. Is there a way to run a "printenv && conda ..." ?

@karrtikr, what are your thoughts here? This looks like another issue where it seems conda might not be activating correctly in the given scenario.

@mattB1989 We do not have access to terminal or terminal profile/init scripts when we run tests, could this be because of that?

@karrtikr I imagineso yes. To run a command like conda, it needs to be in the $PATH, and the way conda inits its shell is to add an alias.

conda init will initialize a shell permanently by writing some shell code in the relevant startup scripts of your shell (e.g. ~/.bashrc). This is done through different functions defined in conda.core.initialize, namely:

conda docs
I don't see how this can work without sourcing a profile somehow ?

@karrtikr, assigning this to you as well so you can follow up while I am out of office- thanks!

Gotcha. Let me explore alternatives for you.

@eleanorjboyd Can you point me to where this command is run:

conda run -n common_env --no-capture-output python ~/.vscode-server/extensions/ms-python.python-2023.14.0/pythonFiles/get_output_via_markers.py -m pytest -p vscode_pytest --collect-only test

I think I found the issue, ideally we should be running these commands using a shell, but we're using exec without a shell:

Adding the shell: true option here to spawnOptions should solve the issue, however it will also make testing slower as launching a shell can take some time.

I'm guessing this is compiled / transpiled so I can't easily test this, can I ?

@karrtikr and @karthiknadig, should I switch this to use shell even if it slows down the testing? Not sure the best answer here.

I think we can potentially use execObservable to just open the shell once, and keep using the same shell for subsequent runs without ever closing it, that way we only pay the price of using the shell exactly once. I recall we used to do the same for isort for sorting imports.

That may be premature though, so I will say switch to using shell for now and explore the above in case it's slow enough to bother users.

@karrtikr @paulacamargo25 do I need to switch to using shell just for the execObservable or do I also need to add it somewhere to work for debugging? Not sure if "shell: true" is used in debugging or if that is handled at another point.

I think debugger uses a shell, so I would suggest to solve this issue just for execObservable for now.