vscode-python: 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>

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 5
  • Comments: 27 (1 by maintainers)

Most upvoted comments

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 https://github.com/microsoft/vscode-python/issues/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?

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

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?