Failure to activate Conda Environments created using the --prefix argument (on Unix)

[DonJayamanne]

• OS - Linux (I believe this should repro on Mac as well)
• Python - Anaconda
• Python version - 3.9

Steps to repro

• Create a conda environment using the cli conda create -p .condaEnv1
• Re-load VS Code and select this as the interpreter
• Create a terminal
• The terminal fails to activate

I believe the code will only work on Windows.

Suggestion

• Leave the code as is for windows
• For Unix the actiavte code can be:
  • Activate one of the other environments such as base (environments with a name)
  • Then activate the current envioronment

What I'm doing in my private extension is:

• Generate activate scripts for a named environment (remove the second set of commands)
• Hard code conda activate -n <path>

I believe this will work.

Problems

• To get this working, we need a list of the conda envioronments when generating the activation code for a specific environment.
  • I can do this in my private extension thats super easy, i have all interperters & the code is super simple
  • WIth Python extension the way it works is we don't know about all of the conda envionrments

Hence not really sure how to proceed with this.
@karrtikr @karthiknadig Let me know if you're happy with me just fetching all of the conda environments & then trying that approach.
At the end of the day, thats better than what we have today, as I don't see how it will work (i.e. its better than nothing).

[karrtikr]

I cannot reproduce this issue in my linux docker container. I assume you meant conda create -p .condaEnv1 python instead of conda create -p .condaEnv1 as we do not support to discover the second kind of env (#18357).

cc/ @karthiknadig were you able to reproduce this when triaged?

Activate one of the other environments such as base (environments with a name)
Then activate the current envioronment

Is this documented somewhere? Not clear on why this is the approach. I'm fine with doing this in the extension itself using list of named envs if need be.

[DonJayamanne]

Is this documented somewhere? Not clear on why this is the approach.

Its not documented, but when using the conda terminal, the base env is always activated as a default & that sets up the necessary paths for activation of other environments.

[karthiknadig]

Why do we need to do -n activation on non-windows? can we ensure that -p activation does not work for non-windows OS? if it does work then we should probably just use that. if the behavior is different between windows and other Os, then this is another bug to file on conda.

[DonJayamanne]

activation on non-windows

based on the docs this is the right way.

[karrtikr]

Let me know if you're happy with me just fetching all of the conda environments & then trying that approach.

I'm fine with this approach, I think the changes would be around

vscode-python/src/client/common/terminal/environmentActivationProviders/condaActivationProvider.ts

Lines 145 to 149 in f55dfb7

	async function getUnixCommands(condaEnv: string, condaFile: string): Promise<string[] | undefined> {
	const condaDir = path.dirname(condaFile);
	const activateFile = path.join(condaDir, 'activate');
	return [`source ${activateFile.fileToCommandArgument()} ${condaEnv.toCommandArgument()}`];
	}

Conda.getEnvList() utility can be used to fetch all environments and then filter base:

vscode-python/src/client/pythonEnvironments/common/environmentManagers/conda.ts

Line 373 in aa49f6d

public async getEnvList(): Promise<CondaEnvInfo[]> {

[karrtikr]

Closing in favor of #20087