What is the right way to update Anaconda and Conda base & environments? - anaconda

Just wondering as what is the right way to update Anaconda and Conda installation and virtual environments. Here is my confusion step by step:
When I run command conda update anaconda, it updates/downgrades alot of packages.
Then I ran conda update conda, which again updates/downgrades some packages.
Next, I ran conda update --update-all it starts downgrading/upgrading different packages.
Lastly, just to make sure that everything's updated, I ran conda update anaconda again. I was expecting a message like Everything's up to date but to my surprise it was again showing a huge list of packages that needed to be updated/downgraded again?
What am I doing wrong here? It appears to me as if I am going in circles with these commands. Any help?

You're not doing anything wrong per se, but it just doesn't make much sense to ever run conda update anaconda and conda update --all right after each other on the same env - they represent two completely different configurations.
Update Anaconda
Anaconda is a Python distribution that bundles together a ton of packages. Presumably, a bunch of testing goes into verifying that all the package versions and builds are compatible with each other. Because this takes time to do, the Anaconda team only releases new distributions (i.e., a new anaconda version) every couple months or so. If you want a stable set of packages that have been tested for interoperability, then do conda update anaconda.
Update All
In between Anaconda releases, new versions of many packages are still released on the Anaconda channel, and if you run conda update --all you're going to inevitably get ahead of the versions specified in the anaconda bundle. If you want the newest individual package releases and don't mind potentially working with package builds that aren't thoroughly tested for integration, then run conda update --all.
It may be worth noting that people who prioritize having access to the latest versions of packages often seem to prefer Conda Forge, because it tends to have more frequent package releases. However, in my opinion, there's almost no point to installing Anaconda if you're going to switch most packages to Conda Forge anyway. Instead, just install Miniconda and only install what you want from Conda Forge at the start.
Update None
Personally, I will rarely run conda update on an env once I've harden the requirements for a project. Every time you update an env, you risk breaking code that you've already written. Instead, Conda makes it quite easy to create new envs, and if they have a lot of overlap with other envs, then the envs can be quite light due to sharing packages across envs via hardlinking.
Update Conda
The one exception to everything above is the conda package, which is the very infrastructure you're using to manage packages and envs. That, one should update just like any other package manager (e.g., a pip or a homebrew).

Found the answers in this useful post by Anaconda
Keeping Anaconda Up To Date
Below is a question that gets asked so often that I decided it would be helpful to publish an answer explaining the various ways in which Anaconda can be kept up to date. The question was originally asked on StackOverflow.
I have Anaconda installed on my computer and I’d like to update it. In
Navigator I can see that there are several individual packages that
can be updated, but also an anaconda package that sometimes has a
version number and sometimes says custom. How do I proceed?
The Answer
What 95% of People Actually Want
In most cases what you want to do when you say that you want to update Anaconda is to execute the command:
conda update --all
This will update all packages in the current environment to the latest version—with the small print being that it may use an older version of some packages in order to satisfy dependency constraints (often this won’t be necessary and when it is necessary the package plan solver will do its best to minimize the impact).
This needs to be executed from the command line, and the best way to get there is from Anaconda Navigator, then the “Environments” tab, then click on the triangle beside the root environment, selecting “Open Terminal”:
This operation will only update the one selected environment (in this case, the root environment). If you have other environments you’d like to update you can repeat the process above, but first click on the environment. When it is selected there is a triangular marker on the right (see image above, step 3). Or, from the command line, you can provide the environment name (-n envname) or path (-p /path/to/env). For example, to update your dspyr environment from the screenshot above:
conda update -n dspyr --all
Update Individual Packages
If you are only interested in updating an individual package then simply click on the blue arrow or blue version number in Navigator, e.g. for astroid or astropy in the screenshot above, and this will tag those packages for an upgrade. When you are done you need to click the “Apply” button:
Or from the command line:
conda update astroid astropy
Updating Just the Packages in the Standard Anaconda Distribution
If you don’t care about package versions and just want “the latest set of all packages in the standard Anaconda Distribution, so long as they work together,” then you should take a look at this gist.
Why Updating the Anaconda Package is Almost Always a Bad Idea
In most cases, updating the Anaconda package in the package list will have a surprising result—you may actually downgrade many packages (in fact, this is likely if it indicates the version as custom). The gist above provides details.
Leverage conda Environments
Your root environment is probably not a good place to try and manage an exact set of packages—it is going to be a dynamic working space with new packages installed and packages randomly updated. If you need an exact set of packages, create a conda environment to hold them. Thanks to the conda package cache and the way file linking is used, doing this is typically fast and consumes very little additional disk space. For example:
conda create -n myspecialenv -c bioconda -c conda-forge python=3.5 pandas beautifulsoup seaborn nltk
The conda documentation has more details and examples.
pip, PyPI, and setuptools?
None of this is going to help with updating packages that have been installed from PyPI via pip, or any packages installed using python setup.py install. conda list will give you some hints about the pip-based Python packages you have in an environment, but it won’t do anything special to update them.
Commercial Use of Anaconda or Anaconda Enterprise
It’s pretty much exactly the same story, with the exception that you may not be able to update the root environment if it was installed by someone else (say, to /opt/anaconda/latest). If you’re not able to update the environments you are using, you should be able to clone and then update:
conda create -n myenv --clone root
conda update -n myenv --all

The other way in is simply,
anaconda-navigator
The resulting GUI image is below, the only difference with respect to this question is where you see "Installed", there is a drop down menu for for "Updatable" and therein you simply click the dependencies for updating for any given environment.
General info
I'm sure everyone knows this, but for anyone who doesn't Anaconda navigator is a point and click GUI already part of the Anaconda and is simply brilliant for managing, installing, updating and deleting all the dependencies.
With respect to the question it is great for managing all the dependencies inside new envs, creating new envs, loading new channels. It works great remotely via X11 if you have Anaconda loaded on a remote cluster/server.
The bonus for me is that I've never known it fail.

conda install conda=4.8.2
works, as it installs a specific version and '''/''' will not spn for long.

Related

How can I do a fresh installation of Python and Jupyter Lab?

I have been using venv to create virtual environments to work with Jupyter Lab. I tried Anaconda for awhile, but couldn't get the widgets working. I went back to a pip,venv setup and everything worked. Then after not using the setup for awhile, Jupyter Lab was freezing when I pressed CTRL+F to find where a variable was being used. It proceeded to freeze even after restarting the kernel, even after deactivating and reactivating the environment. The folder the environment was in won't let me delete it. Creating a new environment to start from scratch didn't fix it. Reinstalling Python and creating a new environment didn't fix it. I see that Pip has cached a lot of the packages and so installing things are pulled from the cached, event after reinstalling Python.
I want to remove everything related to the previous installation and start fresh, but am having trouble doing that. Any advice would be helpful.
Windows 10
Python 3.8.5 is the most recent version used.
Use pip list to list all package (from the old python the one you want to uninstall). Then copy all the packages and put the in a --requirement file with all the packages installed in it. (how to specify --requirement file) Then use the following command to uninstall all the old packages.
pip uninstall [options] -r <requirements file>

Can I remove the anaconda while leaving the conda (Ubuntu)? [duplicate]

I had installed Anaconda on my system before I knew the difference between Anaconda and Miniconda. I would like to downsize to Miniconda since I don't want the bloat of Anaconda, but I already have a handful of environments set up.
So far the only way I can think of migrating is to completely get rid of everything right now, install Miniconda, and then recreate my environments by hand, but that seems quite arduous. Is there a smarter way of going about this?
I agree with #darthbith: Export the envs to YAML files (conda env export) then recreate them once you have Miniconda installed (conda env create).
While there are some experimental tools for packaging and moving envs (i.e., so you avoid having to redownload packages), they only work on a single env basis. So, I can't see how going this route one could avoid making multiple copies of many of the shared files. Instead, if you let Conda handle the environment (re)creation, it will leverage hardlinks to minimize disk usage, and that seems to be one of your aims.
It may be possible to avoid redownloading packages during the environment recreations by retaining the pkgs directory in the root of your Anaconda install, then copying its contents over into the pkgs of the Miniconda install. I would only copy folders/tarballs that don't conflict with the ones that come with Miniconda. After finishing environment recreation, then a conda clean -p would likely be in order, since Anaconda includes many packages that likely aren't getting reused.

How to Fix Entry Point Not Found while installing libraries in conda environment

I'm working on Anaconda by making multiple environments in it. I have made an environment camelot and now I want to install different libraries in this environment. So for example to install pandas in this environment,
I'm writing:
conda install pandas
or
conda install -c conda-forge camelot-py
Then it gives me this error:
python.exe-Entry Point Not Found
The procedure entry point OPENSSL_sk_new_reserve could not be
located in the dynamic link library.
C:\Users\abc\Anaconda3\Library\bin\libssl11_-x64.dll
First I thought it may be because of the environment variable, thus I set an environment variable for Python, but this did not resolve the issue.
as it is suggested in here I could solve this problem by copying libssl-1_1-x64 dlls in Anaconda/DLLS to Anaconda/Library/bin (probably replacing it)
I got the same issue while updating Anaconda navigator, and got it over by replacing the file libssl-1_1-x64.dll in Anaconda3/Library/bin with the one from Anaconda3/DLLs.
As mentioned by an Anaconda maintainer here ...
moving libssl dlls around like that is really not advisable. Those
DLLs are duplicated because you have something fishy going on in your
packages. There should not be any openssl DLLs in the DLLs folder.
They should be in Library/bin
By looking at the JSON files in the conda-meta directory I found out that DLLs\libssl-1_1-x64.dll was installed by the python 3.7.0 package, and Library\bin\libssl-1_1-x64.dll was installed by the openssl package. After further investigation I found out that Python 3.7.0 does not install OpenSSL as a separate package, but Python 3.7.1 (and later) does.
Typically upgrading Python goes as expected, but if you somehow end up with both python 3.7.0 and openssl packages installed simultaneously there will be two libssl-1_1-x64.dll files and your Anaconda distribution will be broken. (You can easily verify this with the conda list command.)
I think the best way to fix it is therefore:
Rename Library\bin\libssl-1_1-x64.dll to Library\bin\libssl-1_1-x64.dll.org (your are going to need it later.)
Copy DLLs\libssl-1_1-x64.dll to Library\bin\libssl-1_1-x64.dll
Update Python to version 3.7.1 or higher, for instance with conda update python. This will remove the DLLs\libssl-1_1-x64.dll file.
Delete the current Library\bin\libssl-1_1-x64.dll file.
Rename Library\bin\libssl-1_1-x64.dll.org back to Library\bin\libssl-1_1-x64.dll. This is necessary because I got HTTP errors in the next step otherwise.
Reinstall OpenSSL with conda install openssl --force-reinstall to ensure it's up to date again.
I had the exact same issue, and it also just started today. Kind of destroyed my entire work day, tbh...
I accidentally did a conda install ... in my base environment, and it updated conda and a handful of other modules. (Conda went from 4.5.12 to 4.7.10, in my case.) Anyway, after I rolled it back, things are working as expected again.
If this is what's causing your issue, here's a fix.
conda list --revisions
conda install --revision 1 (In my case "rev 1" was my most recent, stable base environment.)
(More details about this: https://sriramjaju.github.io/2018-05-30-2-minute-recipe-how-to-rollback-your-conda-environment/)
Now I'm worried that I've inadvertently configured something in a way that isn't compatible with the newest version of conda.
Edit: Don't follow this last suggestion if you're doing anything other than playing around in a conda environment to test-drive modules. See this and this.
Lastly, if you really need to install modules and do some work ASAP, pip install [module name] was still working for me before I thought to do the reversion thing.
My problem was same. I just uninstalled anaconda, and install it again. And the problem solved.
I was receiving the same following error while updating spyder and conda package.
python.exe-Entry Point Not Found
The procedure entry point OPENSSL_sk_new_reserve could not be
located in the dynamic link library.
C:\Users\abc\Anaconda3\Library\bin\libssl11_-x64.dll
solution:
I did replace libssl-1_1-x64 dlls from Anaconda/DLLs to
Anaconda/Library/bins as suggested here.
Before opening Anaconda Navigator desktop app, I updated conda in Anaconda Prompt using conda update conda. conda successfully updated.
Then I have updated spyder using conda update spyder command in
Anaconda Prompt. spyder updated and running successfully.
For those still having similar issues with libssl11_-x64.dll or other .dll files:
Use pip install instead if you can!
I had the same issue today with libcrypto-1_1-x64.dll when trying to install plotly using
conda install -c plotly plotly
This prompts a downgrade for anaconda, and in turn raises the error:
OPENSSL_sk_new_reserve [...] libcrypto-1_1-x64.dll
Instead, using for example
pip install plotly==4.1.0
works like a charm!

Conda hangs in "solving environment" when installing STSci packages

I run Ubuntu 18.04.1 LTS on a virtual machine on Windows 10. I've installed Anaconda 5.3 without any issues, but when I try to install an STSCI environment with the command line:
conda create -n astroconda stsci
the terminal gets stuck in "Solving Environment" (I have version 4.5.11 of conda). Yesterday I waited for about 4 hours before giving up. I would like to know if there is a known issue about this problem and if it can be related to the quantity of disk and RAM assigned to the virtual machine.
I will write a more general solution, to Conda's "Solving Environment" issue, which I had the uttermost pleasure with.
Short answer of things to try:
As already mentioned try updating Conda with conda update conda or even better, the whole base environment conda update --all.
Specify package and build version using <package>=<version>=<build> e.g. sage=8.3=py27_3. Search available versions by conda search <package>.
Like for the package, you can also specify python version and ideally some other dependencies. Check dependencies with conda info <package>.
Check current configuration inside the .condarc file or with conda config --get and check if you maybe have additional restrictions, as normally you will only find the channels defined there.
When working with additional channels put conda-forge or the channel you want to use on top and add channel_priority: strict. So your .condarc file would look like this:
channel_priority: strict
channels:
- conda-forge
- defaults
Contrariwise to the above, remove the first line and try adding --no-channel-priority to the command. This one helped me a couple times since updating to Conda 4.6.
If above does not work:
When conda seem stuck it is possibly having too many options or some conflicts resulting in the SAT solver getting clause counts of multiple millions.
To check if this is the case add -vv or --debug and you will later see lines like Invoking SAT with clause count: XXX. If it stays at one of these lines for long time, then try specifying version for packages as above. If there seem another issue, try the conda GitHub.
Another useful tip if you are using the conda-forge channel, is to go over their Tips & tricks.
I have the same problem on macOS 10.13.6.
The creation of iraf environment
conda create -n iraf27 python=2.7 iraf-all pyraf-all stsci
works fine instead.
Update: I found out that specifying the python version
conda create -n astroconda python=3.6 stsci
makes the installer work also with astroconda.
I had the same issue but then I updated Conda and it worked...
$ conda update conda

Spyder/Anaconda Navigator will not launch after Installing Geopandas

I'm trying to integrate geopandas, plotly, and shply onto my workbench to make some statistical analysis and visualization easier. I have successfully integrated plotly after using the:
conda install -c plotly plotly
comand in my anaconda prompt. However, when I repeat the process for geopandas
conda install -c conda-forge geopandas
my spyder client and anaconda clients no longer open.
I have tried a few clean uninstall/re-install of the latest anaconda distribution package, but have yet to find a fix. Do I need to create separate environments to work in? How would I go about this? Thank you in advance
(Spyder maintainer here) This kind of problem is usually caused by mixing packages from different channels. In your case, you're mixing packages from the plotly, conda-forge and defaults channels. In particular, defaults (the packages provided by default in Anaconda) and conda-forge are binary incompatible because their packages are compiled differently.
To avoid this, you need to uninstall and reinstall Anaconda because you corrupted it. Then you can simply run
conda install plotly geopandas
given that these two packages are part of the defaults channel.

Resources