How does using conda to install a package change my python version and remove conda?

Cause

Changing Python versions without updating the conda package breaks Conda. . The Python version change (2.7.14 -> 3.6.8) created a situation where the new python has a new site-packages which no longer contains a conda package, whereas if you only update within 2.7.x, this wouldn't be an issue.

Conda includes both a set of binaries (e.g., what you're invoking when you type conda in a shell) and a Python package by the same name. The Python package is necessary for Conda as a whole to function and it get's loaded whenever you try to use conda.

It is problematic that many packages on Anaconda seem to be triggering Python version changes, but not subsequently triggering a conda package update. This sounds like something the dependency resolver is overlooking - i.e., default behavior should be to protect integrity of base environment where conda lives.

Trying to Recover

One possible route to recovery is to temporarily use a standalone build of the conda-exec to repair your base env. You can do all the following from any directory, so maybe use a temp or wherever you put downloads. Please report in the comments if this works or needs adjusting!

1. Download the appropriate standalone Conda for your platform (here we'll use linux-64/conda-standalone-4.9.2). The actual binary will be at conda_standalone/conda.exe in the .tar.bz2 file. Don't mind the .exe it's a binary and should run when called at the shell. I'm going to rename it to conda-exec anyway:

   # download archive
   wget -qO conda-standalone-4.9.2.tar.bz2 https://anaconda.org/conda-forge/conda-standalone/4.9.2/download/linux-64/conda-standalone-4.9.2-ha770c72_2.tar.bz2
   
   # extract only the binary and rename
   tar -xzOf conda-standalone-4.9.2.tar.bz2 standalone_conda/conda.exe > conda-exec
   
   # add executable permissions
   chmod +x conda-exec
   

2. Temporarily set CONDA_ROOT_PREFIX to the base of your install. Typically this is the anaconda3 or miniconda3 folder; in this case, we'll use the path given by OP:

    export CONDA_ROOT_PREFIX=/home/me/anaconda2
   

3. Test that it works:

    ./conda-exec info
   

   The key thing to check for is that base environment: correctly identifies to where your base env is and shows it as (writable). You should also see the pkgs folder in your base env in the package cache: .

Option 1: Reverting to Previous Revision

4. Identify the revision immediately before the current one (we'll denote it by <k-1> here), and attempt to restore it:

    ./conda-exec list -n base --revisions
    ./conda-exec install -n base --revision <k-1>
   

   If this works, you should be done. Start a new shell and try using conda again. Otherwise, the other option is...

Option 2: Install conda for the Current Python

4. (Re-)Install the conda package in the base env:

    ./conda-exec install -n base conda
   

   Make sure that the build of Conda that is suggested corresponds to the version of Python currently installed. The --force-reinstall flag might be useful if it claims the requirement is already satisfed.

Try a new shell and see if conda is working. You don't need to keep the conda-exec around.

Last Recourse

If all else fails you may just have to reinstall. Others have reported installing in other directories and being able to still use and access their envs.

Preventions

Avoiding Breakage through Better Practice

First, just a general (opinionated) recommendation: leverage virtual envs more. This isn't directly solving the problem, but it will help you have a workflow that is significantly less prone to encountering such pitfalls. You shouldn't have accepted such a huge change in the first place, not to base. Personally, I rarely install things in base outside of infrastructure (emacs, jupyter-related things, conda, etc.).¹ Software packages go into project-specific or at least development-type envs.

For example, were I doing the install shown, I would have made a new env for it

conda create -n tf36 anaconda::tensorflow-gpu python=3.6

or whatever Python version you actually wish to work in.

Direct Solution: Pinning

Conda does support package pinning, and this is the more direct way to ensure you never ruin your base install again by transitioning Python 2 to 3. Namely, in the env's conda-meta folder create a file, pinned and add the line

python 2.7.*

Note that some users have reported similar issues for 3.6 -> 3.7 transitions, so I believe including the minor version here is necessary. See the documentation on pinning.

---

_{[1] Note that I use Miniconda, not the Anaconda installer, so I have more control over base from the start.}