conda init shouldn't activate base environment

[pitrou]

With the new conda init, the base environment is always activated in new shells. I don't think this is helpful. I don't want conda-installed binaries to shadow the system ones by default. Since conda is set up as a shell function as well, this default activation sounds unnecesary.

[kalefranz]

I struggled with this. I agree with you, but it also goes against the momentum of what users expect as current behavior.

I introduced a config parameter auto_activate_base to give us options here. It’s on by default, but easily turned off. And maybe someday it makes sense after lots of messaging to change the default value of that parameter to off.

[pitrou]

In the meantime I've added conda deactivate at the end of my .bashrc, but I suspect the activate-then-deactivate dance makes shell slower to spawn?

[kalefranz]

BTW use conda config --describe for detailed output on all available config parameters, or browse here: https://docs.conda.io/projects/conda/en/latest/configuration.html

[kalefranz]

but I suspect the activate-then-deactivate dance makes shell slower to spawn

Each invocation of conda/activate.py takes about 200 ms. If there are scripts on etc/conda/[de]activate.d, then add to that the shell execution time.

[Hamberfim]

TLDR;

I have been back and forth on this too.
I appreciated that (base) is active by default and it probably makes a lot of sense for single (minimal) env users or those new to conda to see a notification of the active env, but it feels a little intrusive.
The fact the bash shell is back to some reasonable launch times is great improvement in my book.

• Perhaps the active env and display in the prompt should be options during installation or conda init? Having the ability to disable auto_activation_base in .condarc is great but I feel like (base) being active by default would be a somewhat natural assumption. Wouldn't it seem more natural to be able to remove it from the prompt & keep the auto activation on?

• Furthermore, while initially it's good to know what's active, I don't need the constant reminder. I do all kinds of things at the prompt that have nothing to do with what env is active - the bash shell is more than just for Conda.

Nevertheless, I love all the improvements, the speed, the support for more shells, and the pip interoperability direction.

[kalefranz]

Relevant:

$ conda config --describe changeps1
# # changeps1 (bool)
# #   When using activate, change the command prompt ($PS1) to include the
# #   activated environment.
# #
# changeps1: true

On one hand I think it's an interesting idea to add some of this configuration to conda init. On the other hand, since we already have a robust conda config command, we'd really just be duplicating functionality, and that could end up leading to CLI/API bloat and a lot of confusion.

[kalefranz]

related: #8169

[Hamberfim]

Relevant:

$ conda config --describe changeps1
# # changeps1 (bool)
# #   When using activate, change the command prompt ($PS1) to include the
# #   activated environment.
# #
# changeps1: true

On one hand I think it's an interesting idea to add some of this configuration to conda init. On the other hand, since we already have a robust conda config command, we'd really just be duplicating functionality, and that could end up leading to CLI/API bloat and a lot of confusion.

I see...and agreed, no bloat , no duplication :)
I would suggest then that conda config user knowledge/user edu needs more attention so new users can understand, utilize conda config 's power since installation and conda init do not/will not provide the same level of control granularity that conda config provides.
Thanks!! I shall deep dive grok conda config :)

[kalefranz]

The Conda Configuration Engine for Power Users is a blog post I wrote a while back that I don't think has still been fully incorporated into the docs. We have a docs team trying to catch up on the backlog now :)

[Hamberfim]

The Conda Configuration Engine for Power Users is a blog post I wrote a while back that I don't think has still been fully incorporated into the docs. We have a docs team trying to catch up on the backlog now :)

Nice!! :) Thanks
Hope you don't mind but I'm going to tweet the link.

[sscherfke]

This is also a problem for sub shells. They now always activate the base env and deactivate a previously activated env:

$ echo "$CONDA_SHLVL $CONDA_PREFIX"
1 /path/to/conda
$ conda activate test
(test) $ echo "$CONDA_SHLVL $CONDA_PREFIX"
2 /path/to/conda/envs/test
(test) $ bash
$ echo "$CONDA_SHLVL $CONDA_PREFIX"
1 /path/to/conda

This is especially annoying for shells started within neovim or another editor.

[sscherfke]

Something like this in my .bashrc seems to work:

. "$HOME/conda/etc/profile.d/conda.sh"
if [[ -z ${CONDA_PREFIX+x} ]]; then
    export PATH="$HOME/conda/bin:$PATH"
fi

$ which pip
~/conda/bin/pip

$ conda activate test

(test) $ which pip
~/conda/envs/test/bin/pip

(test) $ # Env should still be activated:

(test) $ bash

(test) $ which pip
~/conda/envs/test/bin/pip

(test) $ # Deactivate env in sub shell

(test) $ conda deactivate

$ exit

(test) $ # Env is still active in parent shell

(test) $ conda deactivate

$ which pip
~/conda/bin/pip

[njohnsoncpe-zz]

@sscherfke do you mind briefly explaining the goal of your script?

[sscherfke]

This snippet (below an updated version) does the following:

• conda actviation scripts are sourced
• conda-python is the default python and tools installed in the base env are also available
• the conda base env remains in PATH when another conda env is activated. This way, tools from the base env are still accessible.
• If I spawn a sub-shell (directly or by typing :term in neovim), an active environment remains active.
• If I switch environments in a sub shell and exit the sub shell, the original env remains activated in the parent shell.

. "$HOME/conda/etc/profile.d/conda.sh"
if [[ ":$PATH:" != *":$HOME/conda/bin:"* ]]; then
    export PATH="$HOME/conda/bin:$PATH"
fi

[njohnsoncpe-zz]

@sscherfke Thanks for the clarification. I'm trying to extend this behavior to starting a new terminal in a new window.

[sscherfke]

Looking forward to testing your ideas. :)

[niderhoff]

I could get rid of this behaviour by invoking conda config --set auto_activate_base false, i.e. setting auto_activate_base: false in my .condarc.

However, I have to say this was a really confusing behaviour after reinstalling miniconda. (Since I was used to NOT having all the binaries from the base environment in my PATH ...) and I strongly suggest we make this a user-controlled setting which is part of the install process (like adding everything to PATH was in earlier versions...).

[msarahan]

That's why we have a message about auto_activate_base in the output from the installer. Not everyone reads it, but we can't possibly satisfy both people who want it activated by default, and people who don't. Newbies are more in the former camp, so we optimize for them because they're often less able to troubleshoot.

[niderhoff]

Oh then that did in fact slip past my attention, mea culpa. But seeing as this has confused some people (also on stackoverflow) you may want to change that to asking the user in the install process with a default to yes? Just a suggestion.

[kolree]

I looked at https://www.anaconda.com/conda-configuration-engine-power-users/ mentioned above and saw that config params for conda can be set using env variables.

This works for me now in bash scripts (where i don't want the default behavior)

export CONDA_AUTO_ACTIVATE_BASE=false; eval "$(conda shell.bash hook)"

[mikkokotila]

Newbies are more in the former camp, so we optimize for them because they're often less able to troubleshoot.

I don't think this makes much sense in that case. My understanding is that newbies are less likely to read information that is provided for them, and also having an environment already active I believe leads to the case where the said newbie ends up creating envs inside envs, and other issues.

[mingwandroid]

It's not easy to create envs inside other envs without really trying to do so (you have to use the less common, less documented -p option to do that and even then I expect conda might prevent it). It does not happen by default. Envs are all created in the envs subdir of the root of the installation unless -p and an explicit path are specified.

[niderhoff]

Basically any installer asks the user if the new binaries should be added to PATH automatically. This is kind of the behavior I have learned to expect from installers that fiddle with my environment variables. Therefore, I think there is no problem asking the user if the default environment should be activated automatically?

[Konfekt]

Each invocation of conda/activate.py takes about 200 ms.

Even with auto_activate_base: false set, the benchmarking tools time and hyperfine measure forconda.sh with conda.sh containing

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

around 150 ms on an older notebook. Since shell startup times add up, one could think of wrapping this script into a function

conda_activate() { 
... 
conda activate "$@"
}

to init conda when activated on demand.

[mingwandroid]

conda init already exists and is very different from what you propose though. We would need a different name. conda_hook_shell_fn is better I think.

[mingwandroid]

Ah you edited it, well, still conda activate exists and is also very different from this.

[Konfekt]

A natural name for the function that calls the code managed by conda init would be conda_setup

[Fravadona]

I've had a few CentOS 7 users that couldn't use their desktop (gnome-shell) anymore because of conda. The reason is that the gnome-shell relies on the system's Python and that the user's .bashrc is loaded during graphical logins...
conda's default activation isn't a good/safe behaviour.

[Piste]

Despite this topic being closed, I'd like to add my voice to those who were surprised to see (base) in all shells after installing Conda. I thought I'd installed a package manager (also dev and env mgr). I didn't expect it to start every single time. I can run it when I want it, no need to auto-run it by default.

[github-actions]

Hi there, thank you for your contribution!

This issue has been automatically locked because it has not had recent activity after being closed.

Please open a new issue if needed.

Thanks!