767

I recently installed anaconda2 on my Mac. By default Conda is configured to activate the base environment when I open a fresh terminal session.

I want access to the Conda commands (i.e. I want the path to Conda added to my $PATH which Conda does when initialised so that's fine).

However I don't ordinarily program in python, and I don't want Conda to activate the base environment by default.

When first executing conda init from the prompt, Conda adds the following to my .bash_profile:

# >>> conda initialize >>>
# !! Contents within this block are managed by 'conda init' !!
__conda_setup="$('/Users/geoff/anaconda2/bin/conda' 'shell.bash' 'hook' 2> /dev/null)"
if [ $? -eq 0 ]; then
    eval "$__conda_setup"
else
if [ -f "/Users/geoff/anaconda2/etc/profile.d/conda.sh" ]; then
    . "/Users/geoff/anaconda2/etc/profile.d/conda.sh"
else
    export PATH="/Users/geoff/anaconda2/bin:$PATH"
fi
# fi
unset __conda_setup
# <<< conda initialize <<<

If I comment out the whole block, then I can't activate any Conda environments.

I tried to comment out the whole block except for

export PATH="/Users/geoff/anaconda2/bin:$PATH"

But then when I started a new session and tried to activate an environment, I got this error message:

CommandNotFoundError: Your shell has not been properly configured to use 'conda activate'.

This question (and others like it) are helpful, but doesn't ultimately answer my question and is more suited for linux users.

To be clear, I'm not asking to remove the (base) from my $PS1 I'm asking for Conda not to activate base when I open a terminal session.

DryLabRebel
  • 8,923
  • 3
  • 18
  • 24
  • 2
    Have you tried to use `source activate` instead? aka "the oldschool method" – jena Nov 15 '19 at 19:30
  • 19
    this question is so useful that should be in the anaconda documentation IMO – fabiob Oct 30 '20 at 12:36
  • 2
    @fabiob Some of the comments in the accepted answer explain where the information can be found. In my opinion it should be one of the first things you learn in the tutorial. Beginners shouldn't have to go pouring over the documentation for such a simple and, evidently, extremely common request. – DryLabRebel Nov 05 '20 at 01:39

8 Answers8

1581

I have conda 4.6 with a similar block of code that was added by conda. In my case, there's a conda configuration setting to disable the automatic base activation:

conda config --set auto_activate_base false

The first time you run it, it'll create a .condarc in your home directory with that setting to override the default.

This wouldn't de-clutter your .bash_profile but it's a cleaner solution without manual editing that section that conda manages.

mareoraft
  • 3,474
  • 4
  • 26
  • 62
jieong
  • 15,842
  • 1
  • 8
  • 4
  • 4
    Great. Where'd you find out about the setting? Because I don't remember reading it anywhere in the introductory tutorials? – DryLabRebel Feb 07 '19 at 23:25
  • Why was this added by conda in your case? – m13op22 Feb 19 '19 at 23:10
  • 11
    @DryLabRebel It's not mentioned in any Release Notes, but you can find it described in the configuration options by running `conda config --describe`. Searching the codebase for "auto_activate_base" appears to show Conda v4.6.0 is the introduction. – merv Mar 10 '19 at 19:57
  • 2
    Oops, missed your question. Sorry! @merv is correct in that it's in the config. I was looking at different options for a different issue and saw that option. – jieong Mar 22 '19 at 02:04
  • 8
    @DryLabRebel After installer initialized Anaconda, it prints out: If you'd prefer that conda's base environment not be activated on startup, set the auto_activate_base parameter to false: `conda config --set auto_activate_base false` Thank you for installing Anaconda3! – Zhi Yuan Aug 25 '19 at 14:48
  • 1
    I'd like to add that you have to restart the terminal to see the change taking effect. +1 to this solution. – Nasif Imtiaz Ohi Sep 04 '19 at 19:35
  • 31
    Thanks so much for this answer. IMO this should be the default behavior. For those with Linux who may be wondering if they should follow the linked Linux question, just follow this it seems to work regardless of OS (Linux Mint here) – Kamel Oct 27 '19 at 17:34
  • How do I change the default env to launch? For example I want to activate "[some env]" rather than "base"? – Jeff Feb 12 '20 at 22:36
  • This does not appear to be effective on windows. Tried running it from both normal and admin elevated Anaconda prompts, with no effect after restarting the terminal. Conda version is 4.8.3 – Chris Apr 14 '20 at 03:58
  • @Chris Did you check the configuration file (`.condarc`) to see if the change was made there? – AMC Jun 11 '20 at 00:41
  • 1
    I've run that config command and the setting is saved in my `~/.condarc` (using conda 4.8.3 on macOS 10.14.5), but every time I start a new shell, "base" gets activated instead of the environment that was last active. What could be causing trouble? Maybe this feature just doesn't do what I expect. It seems that if I start a subshell in the same window, "base" doesn't get activated, but if I start a shell in a new window (effectively a new login), it does activate "base". – Mr. Lance E Sloan Jul 10 '20 at 17:56
  • What will happen during the activation? If I comment those lines in bash_profile to prevent the activation, what will happen? Can I use conda yet? – Mahdi Amrollahi Aug 23 '20 at 01:25
  • 1
    From conda.io : This setting controls whether or not conda activates your base environment when it first starts up. You'll have the conda command available either way, but without activating the environment, none of the other programs in the environment will be available until the environment is activated with conda activate base. People sometimes choose this setting to speed up the time their shell takes to start up or to keep conda-installed software from automatically hiding their other software. – Mahdi Amrollahi Aug 23 '20 at 02:27
  • 2
    Thanks, this helps me a lot. To activate it back, just use 'conda activate' – Hashan Shalitha May 09 '21 at 07:27
  • 1
    Wow.... I was searching this answer for almost 2 years...Finally got the answer today...Worked for my Arch Linux as well – Deepak Oct 04 '21 at 14:00
  • getting `CondaValueError: Key 'auto_activate_base' is not a known primitive parameter.` error, how to solve it? – mirodil Nov 15 '22 at 05:03
  • Yes, this solution works for MacOS also (M chips). Just running `conda config --set auto_activate_base false` in the terminal is enough. – Pawara Siriwardhane May 21 '23 at 08:49
165

There're 3 ways to achieve this after conda 4.6. (The last method has the highest priority.)

  1. Use sub-command conda config to change the setting.

    conda config --set auto_activate_base false
    
  2. In fact, the former conda config sub-command is changing configuration file .condarc. We can modify .condarc directly. Add following content into .condarc under your home directory,

    # auto_activate_base (bool)
    #   Automatically activate the base environment during shell
    #   initialization. for `conda init`
    auto_activate_base: false
    
  3. Set environment variable CONDA_AUTO_ACTIVATE_BASE in the shell's init file. (.bashrc for bash, .zshrc for zsh)

    export CONDA_AUTO_ACTIVATE_BASE=false
    

    To convert from the condarc file-based configuration parameter name to the environment variable parameter name, make the name all uppercase and prepend CONDA_. For example, conda’s always_yes configuration parameter can be specified using a CONDA_ALWAYS_YES environment variable.

    The environment settings take precedence over corresponding settings in .condarc file.

References

Simba
  • 23,537
  • 7
  • 64
  • 76
  • 1
    great answer. i use the env var method within scripts to control this behavior like so: `export CONDA_AUTO_ACTIVATE_BASE=false; eval "$(conda shell.bash hook)"` – Kevin Olree Jan 17 '20 at 20:25
  • 3
    I had to add `export CONDA_AUTO_ACTIVATE_BASE=false` to my .zshrc for option 3 to work. – normanius Apr 01 '20 at 16:49
  • 1
    I tried everything in this thread and nothing seemed to work until I closed and reopened VS Code. Don't forget to restart the application after changing the settings! – Ian May 24 '21 at 00:50
  • 3
    I have `export CONDA_AUTO_ACTIVATE_BASE=false` in my .bashrc and it doesn't make a difference – theo-brown Apr 07 '22 at 16:10
  • 1
    It works for me when I put it before the conda block in the .bashrc, so that conda knows that during the initialization. – Peruz Mar 09 '23 at 15:00
48

The answer depends a little bit on the version of conda that you have installed. For versions of conda >= 4.4, it should be enough to deactivate the conda environment after the initialization, so add

conda deactivate

right underneath

# <<< conda initialize <<<
darthbith
  • 18,484
  • 9
  • 60
  • 76
  • 9
    That should work, and should generalise. But I would prefer a solution that declutters my bash profile, rather than adds to it. – DryLabRebel Feb 03 '19 at 20:10
  • Whether you can declutter depends on what version of conda you have. If I understand correctly, once you have conda 4.6, you only need the `__conda_setup` function, so you could get the whole thing down to 6 lines. But I don't think there's much to declutter here... – darthbith Feb 03 '19 at 23:05
  • 2
    But if you manually edit that section, then conda can no longer automatically manage it. I would suggest just leaving it alone. – darthbith Feb 03 '19 at 23:06
  • That makes sense. I probably won't use Conda enough for that to matter. But it's good advice for anyone else who would. I'll give it the tick. – DryLabRebel Feb 04 '19 at 22:59
  • 4
    Note however, this means that in every terminal session you activate a Conda environment, then deactivate a Conda environment, which you wouldn't notice, but it's not the same as preventing a default activation. – DryLabRebel Feb 04 '19 at 23:06
  • 7
    This doesn't work, opening a new shell with the appended conda code in .zshrc i get pushed into the (base) envronment every time. – Merlin Jul 18 '19 at 22:38
  • 3
    exactly as Merlin said, starting new terminal leads to have (base) again – jreft56 Sep 02 '19 at 06:14
  • @Merlin perhaps your issue is specific to zsh? Did you try the accepted answers solution? – DryLabRebel Sep 11 '19 at 23:12
  • @DryLabRebel I did append the code snippet to zshrc, and now conda does not activate on its own. I dont like the solution and there is prob a cleaner way w a config setup, but i dont have more time to invest. – Merlin Sep 16 '19 at 17:04
  • This is a bad method, it's better to use the official method whenever available. – Shriraj Hegde Oct 28 '21 at 10:05
41

To disable auto activation of conda base environment in terminal:

conda config --set auto_activate_base false

To activate conda base environment:

conda activate
kurianmat
  • 560
  • 4
  • 5
  • 4
    Hey, This answer is correct, but is virtually identical to the accepted answer. My question is not concerned with activating condo, this is one of the first things you learn when going through the tutorials. Consider adding some helpful, relevant information not yet provided in the previous answers. – DryLabRebel Sep 11 '19 at 23:09
  • 9
    I was looking for how to manually activate after disabling auto. Thanks! – eigil Nov 21 '19 at 18:50
  • 1
    This helped. I was also looking for how to manually activate conda after disabling the auto-activate. – Chris Njuguna Jan 08 '20 at 14:42
30

So in the end I found that if I commented out the Conda initialisation block like so:

# >>> conda initialize >>>
# !! Contents within this block are managed by 'conda init' !!
# __conda_setup="$('/Users/geoff/anaconda2/bin/conda' 'shell.bash' 'hook' 2> /dev/null)"
# if [ $? -eq 0 ]; then
    # eval "$__conda_setup"
# else
if [ -f "/Users/geoff/anaconda2/etc/profile.d/conda.sh" ]; then
    . "/Users/geoff/anaconda2/etc/profile.d/conda.sh"
else
    export PATH="/Users/geoff/anaconda2/bin:$PATH"
fi
# fi
# unset __conda_setup
# <<< conda initialize <<<

It works exactly how I want. That is, Conda is available to activate an environment if I want, but doesn't activate by default.

DryLabRebel
  • 8,923
  • 3
  • 18
  • 24
  • 6
    Unfortunately, if the block contents are managed by other scripts, as stated at the start of the code block, this change may get replaced or rolled back by other scripts. – Kukanani Sep 18 '19 at 19:49
  • @DryLabRebel - did you ever find a robust approach that removed the clutter from `rc` file ? I would be interested in this too, being able to just treat conda like other envs, rather than it cluttering things up – baxx Feb 22 '20 at 15:53
  • @baxx no I haven't. If you want the latest version of conda, and you want it to work, then you really need the initialisation commands. – DryLabRebel Feb 23 '20 at 20:23
  • ok cheers, i feel there might be a way around if you just install the conda env in the project dir, not in a centralised location. Not too sure yet – baxx Feb 23 '20 at 20:28
  • This seems like it only has downsides compared to using `conda config --set auto_activate_base false`, can you elaborate? – AMC Jun 11 '20 at 00:37
  • @AMC it is inferior to setting an option in your Conda config. This is why it is not the accepted answer. I left it here however because it does still answer the question. – DryLabRebel Jun 11 '20 at 04:09
  • 3
    Here's what I don't understand: Why can't Conda change the shell settings on the fly (i.e. temporarily) when I call `conda activate` instead of forcing me to permanently change my shell environment? I mean, adding a path to `$PATH` is no problem but I certainly don't want Conda to change my `$PS1`. – balu Jul 07 '20 at 11:11
0

If you manage your .bashrc manually and like to keep it simple, all you really need is:

. "$HOME/anaconda2/etc/profile.d/conda.sh"

See Recommended change to enable conda in your shell.

This will make the conda command available without activating the base environment (nor reading your conda config).

Note that this is (of course) not compatible with managing the conda installation with conda init, but other than that, nothing bad is coming from it. You may even experience a significant speedup compared to the conda init generated code, because this solution avoids calling conda to parse your config files on whether to enable the base environment, etc.

It's best to also keep the if/fi lines to avoid error messages if using the same bashrc on several systems where conda may not be installed:

if [ -f "$HOME/anaconda2/etc/profile.d/conda.sh" ]; then
    . "$HOME/anaconda2/etc/profile.d/conda.sh"
fi

Finally, if you share your bashrc between several systems where conda may be installed in different paths, you could do as follows:

for CONDA_PREFIX in \
   "$HOME/anaconda2" \
   "$HOME/miniconda3" \
   "/opt/miniconda3" \
do
    if [ -f "$CONDA_PREFIX/etc/profile.d/conda.sh" ]; then
        . "$CONDA_PREFIX/etc/profile.d/conda.sh"
        break
    fi
done

Of course, this is now similar in length compared to the conda init generated code, but will still execute much faster, and will likely work better than conda init for users who synchronize their .bashrc between different systems.

coldfix
  • 6,604
  • 3
  • 40
  • 50
  • 3
    _If you want to keep your bashrc simple, you can remove all the conda init generated clutter, and keep only a single line_ The "clutter" which says _!! Contents within this block are managed by 'conda init' !!_ ? What is the advantage of doing this instead of just changing the appropriate Conda setting/config option? – AMC Jun 11 '20 at 00:39
  • 1
    The advantage is cutting 11 lines of unneeded code from bashrc, and improves shell startup time by avoiding to call conda if not needed (conda is pretty slow and can easily add a second or more on the first start just for parsing a value from another config file that says that it shouldn't be activated anyway). Also, this makes your bashrc easier to read which may be relevant to some users. – coldfix Jan 08 '21 at 23:11
  • 1
    By doing this, you will be breaking conda init which manages this automatically, modifying this section is a bad idea – Shriraj Hegde Oct 28 '21 at 10:08
  • The point of this answer is **not to use** `conda init` because the code it generates is slow and doesn't allow you to synchronize your `.bashrc` between different machines... – coldfix Nov 03 '21 at 10:15
  • Thanks for this. I spent some time googling around until I found this recommendation, allowing me to use conda with my own .bashrc file :) – and using the same .bashrc-file across systems. To me it is obvious that the designers of conda didn't really understand the purpose of .bashrc. – Kristjan Jonasson Jan 02 '23 at 08:38
0

for conda 4.12.0 (under WOS) the following worked (where all the previous answers -these included- didn't do the trick):
in your activate.bat file (mine was at ~/miniconda3/Scripts/activate.bat), change the line:

@REM This may work if there are spaces in anything in %*
@CALL "%~dp0..\condabin\conda.bat" activate %*

into

@REM This may work if there are spaces in anything in %*
@CALL "%~dp0..\condabin\conda.bat" deactivate

this line chage/modification doesn't work in the section (of the activate.bat file):

@if "%_args1_first%"=="+" if NOT "%_args1_last%"=="+" (
        @CALL "%~dp0..\condabin\conda.bat" activate
        @GOTO :End
)

maybe because it depends on how your miniconda3 (Anaconda Prompt) executable is set up: %windir%\System32\cmd.exe "/K" some-path-to\miniconda3\Scripts\activate.bat some-path-to\miniconda3 (in my case).

caveat: updating conda overwrites this (activate.bat) file; so one has to modify the above line as many times as needed/updated. not much of a deal-breaker if you ask me.

Manuel F
  • 145
  • 2
  • 7
-3

This might be a bug of the recent anaconda. What works for me:

step1: vim /anaconda/bin/activate, it shows:

 #!/bin/sh                                                                                
 _CONDA_ROOT="/anaconda"
 # Copyright (C) 2012 Anaconda, Inc
 # SPDX-License-Identifier: BSD-3-Clause
 \. "$_CONDA_ROOT/etc/profile.d/conda.sh" || return $?
 conda activate "$@"

step2: comment out the last line: # conda activate "$@"

CcMango
  • 377
  • 1
  • 4
  • 15