`conda` executable deleted by `conda update --all`

If I install a clean copy of Anaconda, and run conda update conda -y && conda update --all -y everything runs fine. But if I install a clean copy of Anaconda and add conda-forge to my channels, something deletes my conda executable the first time I run conda update --all. As best as I can tell, this happens when linking new packages. (If I have a seperate window open, I can run conda info fine until it gets to “Unlinking packages” and “Linking packages” of the conda update --all stage.)

This seems separate from this issue, since I don’t see any uncaught errors.

To reproduce this on my machine (Mac OS 10.11.5), after installing a fresh copy of Anaconda:

conda config --add channels conda-forge
conda update conda
conda update --all

Which yields no error messages until I try conda info and am told -bash: /Users/egentry/anaconda3/bin/conda: No such file or directory

(I believe I’ve properly cleared my old config information between installations)

[kalefranz]

@jjhelmus

First off, conda update --all is nearly always a bad idea. You probably should not be doing that.

It used to be. I thought we had greatly improved it as of 4.0.

I do get an error which leaves conda unusable (requests gets uninstalled and the replacement is not installed before the error)

😤😡

Until we can get conda into it’s own private env and out of the root or “default” env–probably in 5.0–I might just start to vendor all of conda’s dependencies to avoid problems just like this.

We’re also doing structural work within the conda code base to enable us to make things more atomic and roll back on errors.

The error I’m getting is comes when either simplegeneric or python-simplegeneric is installed as the files for it already exist. I think we need to remove the python- prefixed one from conda-forge.

https://github.com/conda-forge/python-simplegeneric-feedstock/issues/1

[jjhelmus]

we introduce an Obsoletes concept, analogous to the RPM meaning.

That would need to be added to conda correct? 👍 for suggesting this as a feature to add to conda. A conflicts option would be nice also for cases where two packages cannot (or should not) be installed in the same environment.