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 @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]

@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.

[itzsimpl]

I can activate the base conda environment by calling conda activate base.

Here's attached a screenshot of creating a new terminal window when I had previously selected the global base conda environment as my current environment

in the list of environments the environment is listed as Python 3.7.5 64-bit ('base': conda) and
the .vscode/settings.json is as follows

{
  "python.pythonPath": "/opt/miniconda3/bin/python"
}

In the /tmp directory I create a local conda environment with the following command

conda create --prefix ./local-env python=3.7

and I can activate the environment by calling

conda activate ./local-env

here is then an attached screenshot of creating a new terminal window when I had previously selected the ./local-env conda environment as my current environment

Note that the environment is present in the subdirectory ./local-env of the current working directory, and in the list of environments the environment is listed as Python 3.7.5 64-bit ('local-env') and the .vscode/settings.json is as follows

{
  "python.pythonPath": "local-env/bin/python"
}

Note that if I create yet another local conda environment

conda create --prefix ./local-env2 python=3.7

the previously created one is then listed as Python 3.7.5 64-bit ('local-env': conda) and the .vscode/settings.json remain as follows

{
  "python.pythonPath": "local-env/bin/python"
}

Note also that the Python extension detects a newly created local envronment (e.g. local-env2) but by selecting yes

the .vscode/settings.json becomes

{
  "python.pythonPath": "/tmp/local-env2/bin/python3.7"
}

[karrtikr]

Thanks for the info. While I try to reproduce this, can you also help me with the following:

instead of:

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

1. I still don't understand where this comes into the picture based on your last comment.

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>

2. If the extension is sending the command mentioned in 1. at any point, I would also need this info I asked earlier.

[itzsimpl]

I appologize, that may have been my mistake. I tried to assess how your two state process works; judging by the value of .vscode/settings.json I assumed that the value of <path_to_activate_script> that you mention is somehow extracted from the <python.pythonPath> value which can be found in .vscode/settings.json. See for example the first screenshot (for base environment), where the two values "match" (one ends with python the other with activate). However, in the case of a local environment this is not true.

[itzsimpl]

Note, however, that there as a difference to /opt/minicodna3/base/bin there is no activate script in ./local-env/bin.

[DonJayamanne]

Please could you let us know what version of conda you have, conda --version.
Thanks

[itzsimpl]

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

[DonJayamanne]

@karrtikr the following is related.

@karthiknadig Added a PR that supported activating environments with paths, see here #8397

Might be good to see whether it works for us. That PR was meant to support activating conda environments created without a name, instead support activating using paths.

[karrtikr]

@itzsimpl please fill the issue template. We would more info such as the extension version.

[itzsimpl]

• VS Code version: Insiders 1.41
• Extension version (available under the Extensions sidebar): Python 2019.11.50794
• OS and version: MacOS 10.14.6, connected via Remote Development tools 0.17.0 (Remote SSH 0.47.2) to a remote 'Debian GNU/Linux 9 (stretch)'
• Python version (& distribution if applicable, e.g. Anaconda): conda 4.7.12
• Type of virtual environment used (N/A | venv | virtualenv | conda | ...): conda global vs local created with conda create --prefix local-path

[petricevich]

I've just had the same issue.

I was unable activate any conda environment other than base due to activate not begin in path which was due to a non-standard installation process (and it seems OP has something similar).
I have made conda available for all users by installing into /opt/miniconda3 and symlinking
/opt/miniconda3/etc/profile.d/conda.sh to /etc/profile.d/conda.sh
This results in an environment where conda is available, but activate isn't, which the extension uses for some reason.

I have solved the issue (for myself) by adding /opt/miniconda3/bin to PATH in .bashrc, as is normally done by the installation script.

Is it possible to make the extension use conda directly if it is already available, instead of trying to activate the default conda env first?

---

• VS Code version: 1.40.2
• Extension version (available under the Extensions sidebar): 2019.11.50794
• OS and version: Ubuntu 19.10 connected to remote Ubuntu 16.04
• Python version: 3.7.4 with miniconda 4.6.14
• Type of virtual environment used (N/A | venv | virtualenv | conda | ...): conda

[karrtikr]

Hey @itzsimpl @cromulen @underchemist ,
I've created #8870 which gives a possible workaround for the issues you face. Please upvote it if you think it would help. You're also welcome to suggest more.

[DonJayamanne]

@karrtikr @karthiknadig
With the latest version of conda and using fully qualified paths to conda, I don't believe we need the old hack of using activate ... & then conda activate (I believe it was added for some jupyter work).

Personally I think we should remove this hack. I.e. we need to fix conda activation just as we have done with conda run.

Besides the requirement is for users of conda 4.6 and later to have their shells initialzed properly using conda init. Anaconda has done a lot of work to resolve initializing of shells in the recent past (e.g. powershell and the like).

Hence I believe the right solution is to deprecate the hack for new versions of conda.
Else we must understand the exact nature of these (hacky) requirements.

[itzsimpl]

I tend to agree with @DonJayamanne, but I'd also upvote the idea mentioned by @karrtikr. From a user's standpoint, it would be good to have the flexibility to change the activation script, if necessary. A working default should however always be provided.

[karrtikr]

Path to activate is incorrectly calculated for environments created using --prefix. We need to deprecate the two step activation and just use the second command conda activate <env_name> here to make this work.

@itzsimpl In that case please upvote the issue #8870. Helps prioritizing it.

[underchemist]

@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.

[Benzyme93]

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?

[simozacca]

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?

[karrtikr]

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

[luabud]

This is now fixed.