Use the default Python rather than the Anaconda installation when called from the terminal

Anaconda adds the path to your .bashrc, so it is found first. You can add the path to your default Python instance to .bashrc or remove the path to Anaconda if you don't want to use it.

You can also use the full path /usr/bin/python in Bash to use the default Python interpreter.

If you leave your .bashrc file as is, any command you run using python will use the Anaconda interpreter. If you want, you could also use an alias for each interpreter.

You will see something like export PATH=$HOME/anaconda/bin:$PATH in your .bashrc file.

So basically, if you want to use Anaconda as your main everyday interpreter, use the full path to your default Python or create an alias. If you want it the other way around, remove the export PATH=.... from bashrc and use full path to Anaconda Python interpreter.

Having tried all the suggestions so far, I think modifying the export statement in file ~/.bashrc, as Piotr Dobrogost seems to suggest, is the best option considering the following:

If you remove the whole statement, you have to use full paths for Conda binaries.

Using Conda 4.4.10 links in the directory anaconda/bin/ point to binaries in the same directory, not the system ones in /usr/bin.

Using this approach you get the system programs for all that have been previously included in $PATH and also the ones specific to anaconda without using full paths.

So in file ~/.bashrc instead of

# Added by the Anaconda3 4.3.0 installer
export PATH="/home/user/anaconda3/bin:$PATH"

one would use

export PATH="$PATH:/home/user/anaconda3/bin"

I faced the same issue and you can do the following.

Go into your .bashrc file and you will find a similar sort of line:

export PATH=~/anaconda3/bin:$PATH

You comment it out and instead type out:

alias pyconda='~/anaconda3/bin/python3'

Or whatever your path is. This worked out for me.

In the year 2020, Conda adds in a more complicated block of code at the bottom of your .bash_profile file that looks something like this:

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

To use the default Python install by default: Simply move this section of code to the very top of your .bash_profile file.

To give yourself the option of using the Conda installed Python: Add this line below the Conda code block above.

alias pyconda="/Users/spacetyper/opt/miniconda3/bin/python3"

Now you should be able to call the system Python install with python and the Conda install with pyconda.

at 2020, like the @spacetyper mentioned, it acted differently. I've found a handy solution for that from this question: How do I prevent Conda from activating the base environment by default?

To disable automatic base activation:

conda config --set auto_activate_base false

it'll create a ./condarc in home directory after running the first time.

I found that, though I remove export=.../anaconda3/bin:$PATH, there is still .../anaconda3/envs/py36/bin(my virtual environment in Anaconda) in PATH, and the shell still uses Anaconda Python.

So I export PATH=/usr/bin:$PATH (/usr/bin is where system Python reside). Though there is already /usr/bin inPATH, we make it searched before the path of Anaconda, and then the shell will use the system Python when you key python, python3.6, pip, pip3 ....

You can get back to Anaconda by using an alias like mentioned above, or default to Anaconda again by comment export PATH=/usr/bin:$PATH.

There are python, python2 and python2.7 shortcuts in both the /home/username/anaconda/bin/ and /usr/bin/ directory. So you can delete any one of them from one folder and use that for the other.

I mean, if you delete the python2 shortcut from the Anaconda directory, you will have the Python for Anaconda version and python2 for the default version in the terminal.

I use Anaconda sparingly to build cross-platform packages, but I don't want to use it as my daily driver for Python. For Anaconda, Ruby, and Node.js projects I've adopted to use environment sand-boxing, which essentially hides functionality behind a function away from your path until you specifically need it. I first learned about it from these two GitHub repositories:

https://github.com/benvan/sandboxd

https://github.com/maximbaz/dotfiles

I have a file of sandboxing functions that looks like this:

.zsh/sandboxd.zsh:

#!/bin/zsh
# Based on
#    https://github.com/maximbaz/dotfiles/.zsh/sandboxd.zsh
# which was originally adapted from:
#    https://github.vom/benvan/sandboxd

# Start with an empty list of all sandbox cmd:hook pairs
sandbox_hooks=()

# deletes all hooks associated with cmd
function sandbox_delete_hooks() {
    local cmd=$1
    for i in "${sandbox_hooks[@]}";
    do
        if [[ $i == "${cmd}:"* ]]; then
            local hook=$(echo $i | sed "s/.*://")
            unset -f "$hook"
        fi
    done
}

# Prepares the environment and removes hooks
function sandbox() {
    local cmd=$1
    # NOTE: Use original grep, because aliased grep is using color
    if [[ "$(type $cmd | \grep -o function)" = "function" ]]; then
        (>&2 echo "Lazy-loading '$cmd' for the first time...")
        sandbox_delete_hooks $cmd
        sandbox_init_$cmd
    else
        (>&2 echo "sandbox '$cmd' not found.\nIs 'sandbox_init_$cmd() { ... }' defined and 'sandbox_hook $cmd $cmd' called?")
        return 1
    fi
}

function sandbox_hook() {
    local cmd=$1
    local hook=$2

    #echo "Creating hook ($2) for cmd ($1)"
    sandbox_hooks+=("${cmd}:${hook}")

    eval "$hook(){ sandbox $cmd; $hook \$@ }"
}

.zshrc

In my .zshrc I create my sandbox'd function(s):

sandbox_hook conda conda

This command turns the normal conda executable into:

conda () {
    sandbox conda
    conda $@
}

An added bonus of using this technique is that it speeds up shell loading times because sourcing a number of wrapper scripts (e.g. nvm, rvm, etc.) can slow your shell startup time.

It also bugged me that Anaconda installed its Python 3 executable as python by default, which breaks a lot of legacy Python scripts, but that's a separate issue. Using sandboxing like this makes me explicitly aware that I'm using Anaconda's Python instead of the system default.

Anaconda 3 adds more than a simple line in my .bashrc file. However, it also backs up the original .bashrc file into a .bashrc-anaconda3.bak file.

So my solution was to swap the two.

For my case, when I had

alias python='/usr/bin/python3.6'

in the ~/.bashrc, it always called python3.6 inside and outside of Anaconda Virtual Environment.

In this setting, you could set the Python version by python3 in each Virtual Environment.