Repository navigation
Miniconda3 environment created with --prefix flag fails to auto activate in terminal #8770
Description
Activity
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) 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 directoryI 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
activatein yourPATH(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.
20 remaining items
- changed the title
[-]Miniconda3 environment fails to auto activate in terminal[/-][+]Miniconda3 environment created with `--prefix` flag fails to auto activate in terminal[/+]on Dec 3, 2019 Iztok Lebar Bajec (@itzsimpl) as a dumb workaround for conda install/distributions without the
activateexecutable 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.Reacted by Suffian KhanFrom 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 ...toconda ...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 erroractivate does not exist. Is it possible to fix this to make it compatible with new conda and please useconda activate ${env}instead? Clearly #8870 would be idealI added
activateto 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?Reacted by Marcin Wrochna and KRiedmillersimozacca Opened #15818 to fix that now. #14123 (comment) is a workaround to fix activation with
source activatecommand.This is now fixed.
- locked as resolved and limited conversation to collaborators
on Sep 24, 2022
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 directoryIn reality in both cases it would be enough if the automatic call was:
instead of: