PATH not set by conda activate

[Atcold]

conda activate does not prepend the correct virtual environment to $PATH on Mac and Linux, therefore the system python takes precedence over the virtual environment one.

How to observe the bug

# Launching new shell
(base) atcold@AlfMAC3 ~ 
$ which python
/usr/local/bin/python  # system python
(base) atcold@AlfMAC3 ~ 
$ conda activate PPUU
(PPUU) atcold@AlfMAC3 ~ 
$ which python
/usr/local/bin/python  # still system python!

Workaround: run conda deactivate.

# Launching new shell
(base) atcold@AlfMAC3 ~ 
$ conda deactivate
atcold@AlfMAC3 ~ 
$ conda activate PPUU
(PPUU) atcold@AlfMAC3 ~ 
$ which python
/Users/atcold/opt/miniconda3/envs/PPUU/bin/python  # virtual environment python
(PPUU) atcold@AlfMAC3 ~ 

Seems like (base) needs to be deactivated first.
Running conda config --set auto_activate_base false adds auto_activate_base: false to ~/.condarc, but the issue remains.

# Launching new shell
atcold@AlfMAC3 ~ 
$ which python
/usr/local/bin/python  # system python
atcold@AlfMAC3 ~ 
$ conda activate PPUU
(PPUU) atcold@AlfMAC3 ~ 
$ which python
/usr/local/bin/python  # still system python!

What is going on

The following line should be sufficient to identify the cause of this bug.
Namely, system python shadows the virtual environment one because conda activate does not prepend the virtual environment path to $PATH, but it inserts it in the middle.

If conda deactivate is called, then the virtual environment path is correctly prepended to$PATH, which leads to the correct and expected behaviour, which has the virtual environment shadowing the system python.

(base) atcold@AlfMAC3 ~  # conda path is inside $PATH
$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/bin:/Library/Apple/bin:/Library/TeX/texbin:/opt/X11/bin:/Users/atcold/opt/miniconda3/bin:/Users/atcold/opt/miniconda3/condabin:/usr/local/miniconda3/bin:/usr/local/cuda/bin:/usr/local/cuda/bin
(base) atcold@AlfMAC3 ~ 
$ conda activate PPUU
(PPUU) atcold@AlfMAC3 ~  # PPUU virtual environment path is inside $PATH
$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/bin:/Library/Apple/bin:/Library/TeX/texbin:/opt/X11/bin:/Users/atcold/opt/miniconda3/envs/PPUU/bin:/Users/atcold/opt/miniconda3/condabin:/usr/local/miniconda3/bin:/usr/local/cuda/bin:/usr/local/cuda/bin
(PPUU) atcold@AlfMAC3 ~ 
$ conda deactivate
(base) atcold@AlfMAC3 ~ 
$ conda deactivate
atcold@AlfMAC3 ~ 
$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/bin:/Library/Apple/bin:/Library/TeX/texbin:/opt/X11/bin:/Users/atcold/opt/miniconda3/condabin:/usr/local/miniconda3/bin:/usr/local/cuda/bin:/usr/local/cuda/bin
atcold@AlfMAC3 ~ 
$ conda activate PPUU
(PPUU) atcold@AlfMAC3 ~  # finally, PPUU virtual environment path is in front of $PATH
$ echo $PATH
/Users/atcold/opt/miniconda3/envs/PPUU/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/bin:/Library/Apple/bin:/Library/TeX/texbin:/opt/X11/bin:/Users/atcold/opt/miniconda3/condabin:/usr/local/miniconda3/bin:/usr/local/cuda/bin:/usr/local/cuda/bin

Hack to fix this bug

Adding conda deactivate to the end of ~/.profile or ~/.bashrc will have conda activate work as expected.

Additional bug

The code added to ~/.profile is buggy (as can be seen here). More precisely there are extra backslashes in \eval and \export.

Conda info

This bug has been verified on a Mac (Catalina) and on a Linux (CentOS 7).

     active environment : base
    active env location : /Users/atcold/opt/miniconda3
            shell level : 1
       user config file : /Users/atcold/.condarc
 populated config files : /Users/atcold/.condarc
          conda version : 4.7.12
    conda-build version : not installed
         python version : 3.7.4.final.0
       virtual packages : 
       base environment : /Users/atcold/opt/miniconda3  (writable)
           channel URLs : https://conda.anaconda.org/pytorch/osx-64
                          https://conda.anaconda.org/pytorch/noarch
                          https://repo.anaconda.com/pkgs/main/osx-64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/r/osx-64
                          https://repo.anaconda.com/pkgs/r/noarch
          package cache : /Users/atcold/opt/miniconda3/pkgs
                          /Users/atcold/.conda/pkgs
       envs directories : /Users/atcold/opt/miniconda3/envs
                          /Users/atcold/.conda/envs
               platform : osx-64
             user-agent : conda/4.7.12 requests/2.22.0 CPython/3.7.4 Darwin/19.0.0 OSX/10.15
                UID:GID : 501:20
             netrc file : None
           offline mode : False

     active environment : base
    active env location : /home/us441/vlad/miniconda3
            shell level : 1
       user config file : /home/us441/.condarc
 populated config files :
          conda version : 4.7.12
    conda-build version : not installed
         python version : 3.7.3.final.0
       virtual packages :
       base environment : /home/us441/vlad/miniconda3  (writable)
           channel URLs : https://repo.anaconda.com/pkgs/main/linux-64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/r/linux-64
                          https://repo.anaconda.com/pkgs/r/noarch
          package cache : /home/us441/vlad/miniconda3/pkgs
                          /home/us441/.conda/pkgs
       envs directories : /home/us441/vlad/miniconda3/envs
                          /home/us441/.conda/envs
               platform : linux-64
             user-agent : conda/4.7.12 requests/2.22.0 CPython/3.7.3 Linux/3.10.0-1062.1.2.el7.x86_64 centos/7.7.1908 glibc/2.17
                UID:GID : 9007:9007
             netrc file : None
           offline mode : False

[msarahan]

Please provide the info requested by the issue template. The conda version in particular is important.

[Atcold]

@msarahan, added conda info for both Mac and Linux machines we're experiencing this issue.
Let me know if you need any further information.

[msarahan]

Thanks. We'll try to look at this soon.

[ndevenish]

I have this issue also, conda 4.8.2. I want to use conda for python, but don't want it to be the default system python. My bashrc block is of the form:

# >>> conda initialize >>>
...
# <<< conda initialize <<<

export PATH=/my/custom/python/bin:$PATH

I've found that I can get the expected behaviour by stripping out the conda initialize block and replacing it with purely:

. "/path/to/working/modules/miniconda3/etc/profile.d/conda.sh"  

With default conda init block in bashrc:

$ which python3
/my/custom/python/bin/python3
$ conda activate conda_base/
$ which python3
/my/custom/python/bin/python3

However with the stripped down conda.sh only:

$ which python3
/my/custom/python/bin/python3
$ conda activate conda_base/
$ which python3
/path/to/working/dist3/conda_base/bin/python3

conda info:

     active environment : base
    active env location : /path/to/working/modules/miniconda3
            shell level : 1
       user config file : /home/username/.condarc
 populated config files : /home/username/.condarc
          conda version : 4.8.2
    conda-build version : not installed
         python version : 3.7.4.final.0
       virtual packages : __cuda=10.1
                          __glibc=2.17
       base environment : /path/to/working/modules/miniconda3  (writable)
           channel URLs : https://conda.anaconda.org/conda-forge/linux-64
                          https://conda.anaconda.org/conda-forge/noarch
                          https://repo.anaconda.com/pkgs/main/linux-64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/r/linux-64
                          https://repo.anaconda.com/pkgs/r/noarch
          package cache : /path/to/working/modules/miniconda3/pkgs
                          /home/username/.conda/pkgs
       envs directories : /path/to/working/modules/miniconda3/envs
                          /home/username/.conda/envs
               platform : linux-64
             user-agent : conda/4.8.2 requests/2.22.0 CPython/3.7.4 Linux/3.10.0-1062.1.2.el7.x86_64 rhel/7.6 glibc/2.17
                UID:GID : 1210865:1210865
             netrc file : None
           offline mode : False

[shoemakerdr]

We ran into this problem at my job. We create static, versioned conda distributions rather than updating in place, so we've had issues with old conda dists to staying around in the path.

The way we've worked around it is by removing all previous conda dists from the path (most people probably won't have this issue unless they have multiple condas) and to put unset CONDA_SHLVL before the conda initialize block in our .bashrc files. This allows this block of code from conda.sh to set up the pathing properly. Note: one issue we've run into with this fix is if you re-source your .bashrc with an activated non-base conda environment, it'll reset it back to the base env, which may/may not be desirable behavior.

Not sure if this is the most effective solution. Maybe conda could provide a config setting like "always_reset_conda_shell" in .condarc? I can submit a PR if that's something you think could be of value. It would certainly help us.

Thanks!

[maximilianh]

Thanks! unset CONDA_SHLVL totally worked for me. I've been suffering from this for a while.

[nikitakuklev]

Seconded - good fix! Solved my somewhat related issues with byobu paths and conda environments.

[mattolenik]

Also working for me, thank you @shoemakerdr!

[Atcold]

@msarahan, what do you say?

[dorianj]

I'm seeing this on a default miniconda 4.8.2, adding conda deactivate to my .zshenv worked. I have no idea what about my configuration causes this bug to surface, my setup is pretty vanilla

[Atcold]

@msarahan, any update?

[aanousakis]

I noticed that it works if i install a packet when i create the environment.

antony@antony-fedora : ~/Workspace/tmp : which python
/usr/bin/python
antony@antony-fedora : ~/Workspace/tmp : conda create --name my_env
antony@antony-fedora : ~/Workspace/tmp : conda activate my_env
(my_env) antony@antony-fedora : ~/Workspace/tmp : which python
/usr/bin/python
(my_env) antony@antony-fedora : ~/Workspace/tmp : conda create --name my_env pip
(my_env) antony@antony-fedora : ~/Workspace/tmp : conda activate my_env
(my_env) antony@antony-fedora : ~/Workspace/tmp : which python
~/anaconda3/envs/my_env/bin/python

[mufernando]

This has been an issue for me with conda 4.8.2.

I confirmed this only happens when you create an environment without specifying any additional packages. Also, adding conda deactivate to the end of my .zshenv fixed it.

[tazihad]

facing same problem in miniconda.

❯ conda info

     active environment : base
    active env location : /home/pulsar/.local/opt/miniconda3
            shell level : 2
       user config file : /home/pulsar/.condarc
 populated config files : /home/pulsar/.condarc
          conda version : 4.8.3
    conda-build version : not installed
         python version : 3.8.3.final.0
       virtual packages : __cuda=11.1
                          __glibc=2.32
       base environment : /home/pulsar/.local/opt/miniconda3  (writable)
           channel URLs : https://repo.anaconda.com/pkgs/main/linux-64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/r/linux-64
                          https://repo.anaconda.com/pkgs/r/noarch
          package cache : /home/pulsar/.local/opt/miniconda3/pkgs
                          /home/pulsar/.conda/pkgs
       envs directories : /home/pulsar/.local/opt/miniconda3/envs
                          /home/pulsar/.conda/envs
               platform : linux-64
             user-agent : conda/4.8.3 requests/2.23.0 CPython/3.8.3 Linux/5.8.16-2-MANJARO manjaro/20.1.2 glibc/2.32
                UID:GID : 1000:1000
             netrc file : None
           offline mode : False

[Atcold]

@msarahan, it's been a year since I've opened this issue.

[ShuchitaBanthia]

I noticed that it works if i install a packet when i create the environment.

antony@antony-fedora : ~/Workspace/tmp : which python
/usr/bin/python
antony@antony-fedora : ~/Workspace/tmp : conda create --name my_env
antony@antony-fedora : ~/Workspace/tmp : conda activate my_env
(my_env) antony@antony-fedora : ~/Workspace/tmp : which python
/usr/bin/python
(my_env) antony@antony-fedora : ~/Workspace/tmp : conda create --name my_env pip
(my_env) antony@antony-fedora : ~/Workspace/tmp : conda activate my_env
(my_env) antony@antony-fedora : ~/Workspace/tmp : which python
~/anaconda3/envs/my_env/bin/python

Great finding! Atleast helps to find a workaround to the problem. I was so boggled and wasted days because of this issue!

[bernt-matthias]

I noticed that it works if i install a packet when i create the environment.
antony@antony-fedora : ~/Workspace/tmp : which python
/usr/bin/python
antony@antony-fedora : ~/Workspace/tmp : conda create --name my_env
antony@antony-fedora : ~/Workspace/tmp : conda activate my_env
(my_env) antony@antony-fedora : ~/Workspace/tmp : which python
/usr/bin/python
(my_env) antony@antony-fedora : ~/Workspace/tmp : conda create --name my_env pip
(my_env) antony@antony-fedora : ~/Workspace/tmp : conda activate my_env
(my_env) antony@antony-fedora : ~/Workspace/tmp : which python
~/anaconda3/envs/my_env/bin/python

Great finding! Atleast helps to find a workaround to the problem. I was so boggled and wasted days because of this issue!

Not sure if this is a workaround. Is there a python installed in the first environment created with conda create --name my_env? If no, then /usr/bin/python would be expected.

In the 2nd environment python comes with pip and also this would then be expected.

[ShuchitaBanthia]

I noticed that it works if i install a packet when i create the environment.
antony@antony-fedora : ~/Workspace/tmp : which python
/usr/bin/python
antony@antony-fedora : ~/Workspace/tmp : conda create --name my_env
antony@antony-fedora : ~/Workspace/tmp : conda activate my_env
(my_env) antony@antony-fedora : ~/Workspace/tmp : which python
/usr/bin/python
(my_env) antony@antony-fedora : ~/Workspace/tmp : conda create --name my_env pip
(my_env) antony@antony-fedora : ~/Workspace/tmp : conda activate my_env
(my_env) antony@antony-fedora : ~/Workspace/tmp : which python
~/anaconda3/envs/my_env/bin/python

Great finding! Atleast helps to find a workaround to the problem. I was so boggled and wasted days because of this issue!

Not sure if this is a workaround. Is there a python installed in the first environment created with conda create --name my_env? If no, then /usr/bin/python would be expected.

In the 2nd environment python comes with pip and also this would then be expected.

So, the issue I have been facing was as follows. Even though python wasn't installed when the environment was created, it was installed later on. However, despite that, on activating the environment, python would still map to /usr/bin/python instead of the one inside the environment. I was able to resolve this issue by adding packages to the initial env creation command.

[bernt-matthias]

Odd.

In my case I always create the environment by specifying the list of packages. I never ever change an environment. Still I have the problem.

[DominikMa]

Had the same problem. In my case it came from my .profile (the default one), which prepends the $HOME/bin:$PATH and $HOME/.local/bin:$PATH. I do not have this on newer systems, only on an Ubuntu 18.04.

[CharlesB2]

I found a fix for the issue by appending the following to condarc (providing that you're using conda for a Python use):

create_default_packages:
  - python

This comes just from the finding form @aanousakis, the issue doesn't happen when installing the python package by default.

[noce2]

Having this issue as well with Miniconda on macOS 11.2.3.

[eugene-yang]

Anyone handling this annoying bug?

[shoemakerdr]

My response above has a workaround to fix this issue: #9392 (comment)

[eugene-yang]

I don't think we want to keep using a workaround instead of actually fixing this issue.
Plus the above workaround doesn't work for me (and I don't really understand why that would work).

[xiumingzhang]

I don't think we want to keep using a workaround instead of actually fixing this issue. Plus the above workaround doesn't work for me (and I don't really understand why that would work).

+1 – none of the workarounds works for me. We need a fix two years after the issue was initially filed.

[GitTorres]

If you are on a mac and only have this issue within the terminal in VS Code, but not otherwise, adding this to the VS Code settings.json fixed it for me.

"terminal.integrated.env.osx": { "PATH": "" }

[TheGustafson]

I'm getting this same issue on windows when using VS Code. 2 years later, has anyone looked at this?

[timyerg]

miniconda3 v.4.11.0
The same issue with python version.
Thank you for the fix.

[KEMBL]

Have the same problem using poweshell on Windows 10, cmd works fine!

[Tu-Zhenzhao]

@Atcold I was able to use your conda deactivate to walkaround this issue but I found a important clue to debug this issue(I was inspired by this post). The key point is your .bashrc or .zshrc existing some commands like export $PATH are affecting your path choosing. You might want to check if any unused command are changing your path setting. Hoping this will help you.

[kcarnold]

I was seeing this with a fish shell in VS Code. Running conda config --set auto_activate_base False (which I found at the docs) seems to have fixed it, while also making the terminal start up faster too. But this is still a bug.

I suspect the more general work-around is: move the conda initialize block to be below any PATH modifications. But I haven't tested this.

[Tu-Zhenzhao]

I was seeing this with a fish shell in VS Code. Running conda config --set auto_activate_base False (which I found at the docs) seems to have fixed it, while also making the terminal start up faster too. But this is still a bug.

I suspect the more general work-around is: move the conda initialize block to be below any PATH modifications. But I haven't tested this.

I believe you are in the right track! Order is very important. I suggest you put every PATH modification before the condo initialize block

[staniPetrox]

I have the same issue and we're speaking the year 2022 of the lord. This bug is open for 3 years now.

[kcarnold]

Two ideas:

1. conda activate could check PATH modifications and warn if anything was changed outside of its control.
2. conda init could be more proactive in preventing this in shell conf-files. At minimum, it could leave a note suggesting that modifications to PATH and similar variables not be placed after its block.

[kenodegard]

TL;DR

Conda respects your PATH order and will not reorder anything upon activation/deactivation but instead finds the currently active environment and replaces it with the new environment.

This is not a bug but expected behavior.

Because of this, moving the conda initialization block to the bottom of your shell profile is the recommended solution (kudos to @Tu-Zhenzhao and @kcarnold for figuring this out).

Discussion

Several other issues are being raised, which made this more confusing than necessary. I will attempt to answer all of the unique issues. If you continue to encounter problems, please open a new issue.

1. @ndevenish PATH not set by conda activate #9392 (comment)

   I want to use conda for python, but don't want it to be the default system python.

   You'd be better off preventing the base environment from being activated on startup:

   conda config --set auto_activate_base false

   That way, your default Python will be the system Python, and you can choose when to activate an environment and use a conda Python.

2. @shoemakerdr @maximilianh @nikitakuklev @mattolenik PATH not set by conda activate #9392 (comment)

   put unset CONDA_SHLVL before the conda initialize block in our .bashrc files

   Sounds like a sub-shelling issue. You probably have something like export PATH="/usr/bin:$PATH" in your shell profile that causes issues for sub-shells. I'd suggest adding proper fencing around these exports, e.g.:

   [[ ":$PATH:" != *":/usr/bin:"* ]] && export PATH="/usr/bin:$PATH"

   Adding unset CONDA_SHLVL anywhere else in your shell profile after the conda initialization block may appear to work but can lead to other issues. It makes conda think that no environment was previously activated, so when you activate another environment, it will simply prepend the new environment to the front of your PATH. In other words, both the new active environment and the base environment will be on your PATH simultaneously and can cause weird behaviors.

3. @shoemakerdr PATH not set by conda activate #9392 (comment)

   Maybe conda could provide a config setting like "always_reset_conda_shell" in .condarc?

   Re-sourcing the shell profile problem is likely best solved by adding a conditional fence around the conda initialization block. If this is still something you'd find valuable, we'd greatly appreciate it if you could open a new issue and outline the problem and use case.

   Additionally, multiuser setups have found value in using tools like TCL or LMOD (see Document using conda init for TCL/LMOD #11087); you may find value in using this for multiconda setups as well for easier toggling between conda versions.

4. @aanousakis @mufernando @ShuchitaBanthia PATH not set by conda activate #9392 (comment)

   I noticed that it works if i install a packet when i create the environment.

   Correct. @bernt-matthias (PATH not set by conda activate #9392 (comment)) and @CharlesB2 (PATH not set by conda activate #9392 (comment)) are both spot on.

   If you create a conda environment without specifying any packages, it will be an empty environment; not even Python will be installed. With an empty environment active, running python will use another version available on your PATH (most likely the system version).

5. For those who used the conda deactivate fix. This is effectively the same as the first answer above:

   conda config --set auto_activate_base false

[ThomasBourgeois]

Sorry guys,
How can you say this is expected behaviour when the environment seems to be activated (with it's name in parenthesis) and is in fact not?
Messed up an environment like this, installing packages somewhere I shouldn't have..

[kmahyyg]

Now in 2024, with fresh installation of miniconda on Mac OS via iTerm2, still suffers from this issue.
Now conda initialization code block is automatically placed on the bottom of .zshrc when installation.

Even I disabled auto-activate base on start, manually conda activate another_env_instead_of_base will NOT replace python3 path.

However, conda activate base will replace python3 path.

This is what happened:

❯ which python3
/usr/bin/python3
❯ conda env list
# conda environments:
#
base                     /Users/username_here/Developer/miniconda3
invguide                 /Users/username_here/Developer/miniconda3/envs/invguide
msftcloud                /Users/username_here/Developer/miniconda3/envs/msftcloud

❯ conda activate msftcloud
❯ which python3
/usr/bin/python3
❯ conda activate base
❯ which python3
/Users/username_here/Developer/miniconda3/bin/python3

I read all above, but still can't figure out a solution. Could someone please help me?

• Update 1: If I activate base or invguide , the python3 path is updated correctly. But with newly created msftcloud, this won't working. I created msftcloud using conda create -n msftcloud, it's weird.
• Update 2: Newly created conda environment does NOT contain any packages, it even does not inherit packages and python interpreter from base, so if you'd like to include python3, check: https://stackoverflow.com/questions/43145667/anaconda-is-not-creating-full-environment , and re-create environment using something like: conda create -n msftcloud python=3.11, then activate this newly created environment.
• Update 3: To permanently "solve" this issue: check PATH not set by conda activate #9392 (comment)