conda install causes active environment to be mislabeled

[water-e]

I am installing miniconda with packages I need. The exact steps preceding my problems are are as follows using windows 64 latest as of 2019-11-15:

install miniconda 
conda update conda
conda info --envs
conda install -n base spyder jupyter 
conda install -n base nb_conda_kernels
conda create -n py37 python=3.7
activate py37
conda config --env --append channels conda-forge
conda config --env --set channel_priority strict
conda install -n py37 spyder-kernels ipykernel
conda install -n py37 conda-build

When I finish the spyder-kernels/ipykernel step, conda info --envs lists a "base" and a "py37" as expected. When I do the conda-build step, the names have seemingly shifted. Here are the output of conda info and conda info --env

(py37) C:\Users\eli>conda info

     active environment : base
    active env location : C:\Users\eli\miniconda3\envs\py37
            shell level : 2
       user config file : C:\Users\eli\.condarc
 populated config files : C:\Users\eli\miniconda3\envs\py37\.condarc
                          C:\Users\eli\.condarc
          conda version : 4.7.12
    conda-build version : 3.18.11
         python version : 3.7.5.final.0
       virtual packages : __cuda=8.0
       base environment : C:\Users\eli\miniconda3\envs\py37  (writable)
           channel URLs : https://repo.anaconda.com/pkgs/main/win-64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/r/win-64
                          https://repo.anaconda.com/pkgs/r/noarch
                          https://repo.anaconda.com/pkgs/msys2/win-64
                          https://repo.anaconda.com/pkgs/msys2/noarch
                          https://conda.anaconda.org/conda-forge/win-64
                          https://conda.anaconda.org/conda-forge/noarch
          package cache : C:\Users\eli\miniconda3\envs\py37\pkgs
                          C:\Users\eli\.conda\pkgs
                          C:\Users\eli\AppData\Local\conda\conda\pkgs
       envs directories : C:\Users\eli\miniconda3\envs\py37\envs
                          C:\Users\eli\.conda\envs
                          C:\Users\eli\AppData\Local\conda\conda\envs
               platform : win-64
             user-agent : conda/4.7.12 requests/2.22.0 CPython/3.7.5 Windows/10 Windows/10.0.10586
          administrator : False
             netrc file : None
           offline mode : False

(py37) C:\Users\eli>conda info --env
# conda environments:
#
                         C:\Users\eli\miniconda3
base                  *  C:\Users\eli\miniconda3\envs\py37

So the names of the available environments have changed -- base is now blank and the environment in py37 seems to be called base. Restarting the anaconda prompt causes things to be temporarily corrected, with the names and locations corresponding. Then if I "activate py37", the two variants of conda info give me the same results as above. The command prompt is OK, so something knows it is in py37, but the labeling is "base".

The use or non-use of the -n flag does not seem critical to reproducing the issue. Contents of .conda/environments.txt are OK:

C:\Users\eli\miniconda3
C:\Users\eli\miniconda3\envs\py37

[dwr-psandhu]

@water-e verified this and this is a conda-build package issue. The conda-build install assumes that it is running from the base environment during install and messes up the conda environments. The work around for now is to do

conda activate base
# stay in base environment but install into py37 environment
conda install -n py37 -c defaults -c conda-forge conda-build

[water-e]

@water-e verified this and this is a conda-build package issue. The conda-build install assumes that it is running from the base environment during install and messes up the conda environments. The work around for now is to do

conda activate py37
# stay in base environment but install into py37 environment
conda install -n py37 -c defaults -c conda-forge conda-build

Thanks. Do you mean conda activate base (first line).

[water-e]

@water-e verified this and this is a conda-build package issue. The conda-build install assumes that it is running from the base environment during install and messes up the conda environments. The work around for now is to do

conda activate py37
# stay in base environment but install into py37 environment
conda install -n py37 -c defaults -c conda-forge conda-build

Thanks. Do you mean conda activate base (first line).

Also do you have any idea how deep the error is that is caused by this? Many things seem to be installed in the right spot, Is there a config file where I can set the labeling straight or do I go through a full reinstall?

[water-e]

Based on some new experiments, the workaround of installing from base into the destination environment with -n reduces bad bahavior. But there is some insidious stuff remaining. For instance if I install conda-build in py37, activate py37 then activate base, I remain in py37.

[zakv]

I've also seen these issues when installing conda-build in a non-base environment. However as suggested here https://github.com/conda/conda-build/issues/3813#issuecomment-660988610 it seems that they are more directly related to conda. I've managed to reproduce them just by installing conda in a non-base environment without installing conda-build.

Maybe the issue is that conda just assumes it's running in the base environment? And then a second issue is that when a package depends on conda, installing that package in a non-base environment also installs conda in that environment which leads to trouble?

I've seen this behavior, namely the mislabeled conda env list output and the issues with conda activate, when using the "Anaconda Prompt". Strangely the "Anaconda Powershell Prompt" doesn't exhibit this behavior and seems to work fine.

[bigfrog10]

With the latest version, seems installation is working fine now for conda-build. However, every time when I run a conda build in a nonbase env, the environment is messed. See the pictures at the end of this link: https://github.com/psilons/pypigeonhole-build/blob/master/docs/impl_notes.md. This is for windows. Linux is fine.

To reproduce, create a new conda env and activate it. Go into the project folder. run conda env list to make sure environments are good.

Then run

conda-build bbin\pkg_conda_cfg --output-folder dist_conda

now run conda env list again. The print should be the second picture in the link.

Could you please take a look? The only way that I can do is to kill the window and open a new one.

Thanks!

[chrisjbillington]

One possible solution is for conda to be split into two packages, one containing the Python modules, and one containing everything else (e.g. CLI scripts). conda-build only requires the python modules, so it could depend on for example libconda and not conda (which would also depend on libconda).

[github-actions[bot]]

Hi there, thank you for your contribution!

This issue has been automatically marked as stale because it has not had recent activity. It will be closed automatically if no further activity occurs.

If you would like this issue to remain open please:

1. Verify that you can still reproduce the issue at hand
2. Comment that the issue is still reproducible and include:
   • What OS and version you reproduced the issue on
   • What steps you followed to reproduce the issue

NOTE: If this issue was closed prematurely, please leave a comment.

Thanks!