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!
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
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
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
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
(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.).1 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.