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)
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 erroractivate does not exist
. Is it possible to fix this to make it compatible with new conda and please useconda activate ${env}
instead? Clearly https://github.com/microsoft/vscode-python/issues/8870 would be idealI 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 ...
& thenconda 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 usingconda 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 addto 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?