Miniconda3 environment created with `--prefix` flag fails to auto activate in terminal

[itzsimpl]

I have a Debian system with miniconda3 installed and two environments: a global one ('base': conda) and a local one ('.conda-env': conda). When selecting the global one and creating a new terminal window the environment is correctly activated via the following commands:

$ source /opt/miniconda3/bin/activate
(miniconda3) $ conda activate base
(miniconda3) $

Whereas if I select the local one, the activation does not take place:

$ source activate .conda-env
bash: activate: No such file or directory

In reality in both cases it would be enough if the automatic call was:

$ conda activate <environment>

instead of:

$ source <python.pythonPath>
$ conda activate <environment>

[DavidKutu]

Hi Iztok Lebar Bajec (@itzsimpl), thanks for filing this. I can't test it right now (i'm on windows 10) but we'll definitely look into it.

[DonJayamanne]

David Kutugata (@DavidKutu) this isn't a ds issue.

[karrtikr]

Whereas if I select the local one, the activation does not take place:

$ source activate .conda-env
bash: activate: No such file or directory

I am confused here, which of these activation scripts do you see when you select a local one? Is it this one, or the one I am mentioning below?

So when you open a new terminal, you should the following commands. I assume you're using conda version greater than 4.4

$ source <path_to_activate_script>
$ conda activate <environment>

[itzsimpl]

I am using conda 4.7.12 and Visual Studio Code Insiders version 1.41.

The two commands that are being executed are those that you mention, but they work only for the global environment, not for a local one. More precisely, what happens with a local environment, created in /tmp/local, is:

$ source activate local
bash: activate: No such file or directory

I am wandering why is it necessary to use a two stage activation (source, followed by conda activate), as the environment, global or local, can be activated simply by passing the environment name or local folder, i.e.

$ conda activate base

will activate the global base environment, and

$ conda activate ./local

will activate the local environment that is setup in subdirectory ./local.

[karrtikr]

Here's a comment I found justifying the block of code sending two activation scripts,
https://github.com/Microsoft/vscode-python/blob/f9c1f97f74dbd8faa630a8115664c03c43855939/src/client/common/terminal/environmentActivationProviders/condaActivationProvider.ts#L58-L61

// Algorithm differs based on version
// Old version, just call activate directly.
// New version, call activate from the same path as our python path, then call it again to activate our environment.
// -- note that the 'default' conda location won't allow activate to work for the environment sometimes.

I am not aware the purpose of /tmp/local, so not sure why you see this

$ source activate local
bash: activate: No such file or directory

there. But I don't think the commands the extension sends should translate to this. The above command assumes you've activate in your PATH (which is why it fails), whereas the command we're sending does not.

Can you send the screenshot of what error message pops up when the extension sends the command below?

$ source <path_to_activate_script>
$ conda activate <environment>

Thanks for cooperating.

[DonJayamanne]

Iztok Lebar Bajec (@itzsimpl) We have attempted to resolve this issue in the latest insiders version of the extension.
Kartik Raj (@karrtikr) conda run should have resolved this depending on the version of conda installed on user machine.

[karrtikr]

Maybe I misunderstand, but he's just creating a new terminal and not running files in terminal, so isn't conda run unrelated to this?
We should still activate conda when a new terminal is created, shouldn't we?