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

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>

Iztok Lebar Bajec (@itzsimpl)

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.

David Kutugata (@DavidKutu)

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

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>

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.

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.

Iztok Lebar Bajec (@itzsimpl)

Iztok Lebar Bajec (@itzsimpl) as a dumb workaround for conda install/distributions without the activate executable you can add

#!/bin/bash

conda activate $@

to a directory in your path and now when source activate <env> is called by vs code in the integrated terminal it will activate the environment as expected.

From condaActivationProvider.ts:

public async 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()}`];

Wouldn't changing the return statement here from source ... to conda ... fix this? Or are there conda tool versioning issues that also need to be considered?

With newer versions of conda, the activating command source activate ${env} is not by default added by conda initialization and vscode fails to activate any virtual environment with error activate does not exist. Is it possible to fix this to make it compatible with new conda and please use conda activate ${env} instead? Clearly #8870 would be ideal

I added activate to my .bashrc but does anyone any other temporary workaround? I consider this to be a very disruptive issue that might be very easy to solve?

simozacca

simozacca Opened #15818 to fix that now. #14123 (comment) is a workaround to fix activation with source activate command.

This is now fixed.

Navigation Menu

Repository navigation

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

20 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

DavidKutu commented on Nov 25, 2019

DonJayamanne commented on Nov 25, 2019

karrtikr commented on Nov 27, 2019

itzsimpl commented on Nov 27, 2019

karrtikr commented on Nov 27, 2019

DonJayamanne commented on Nov 27, 2019

karrtikr commented on Nov 27, 2019

20 remaining items

underchemist commented on Jun 2, 2020

bw-turner commented on Dec 19, 2020

simozacca commented on Jan 28, 2021

karrtikr commented on Apr 6, 2021

luabud commented on Aug 24, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

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