Managing packages: PyCharm vs conda vs pip - python

I'm new to Python and recently installed PyCharm 2016.3 on Windows 10. I'm also using Anaconda 3.
I don't know much about package management and would like to understand it better. Normally I just use conda update --all but I noticed (by checking the package list of my local PyCharm Interpreter) that this doesn't upgrade all packages to the latest version.
One such package is Pillow of which there's a version 4.0.0 but conda (4.3.11) won't update it past 3.4.2. I tried conda install pillow: 4.0.0 and got:
UnsatisfiableError: The following specifications were found to be in conflict:
- pillow 4.0.0*
- python 3.5*
- spyder-app
Use "conda info <package>" to see the dependencies for each package.
Later I found out that Pillow is also available on conda-forge so I tried conda install -c conda-forge pillow=4.0.0 and got:
The following NEW packages will be INSTALLED:
libiconv: 1.14-vc14_4 conda-forge [vc14]
libxml2: 2.9.3-vc14_9 conda-forge [vc14]
olefile: 0.44-py35_0 conda-forge
vc: 14-0 conda-forge
The following packages will be UPDATED:
freetype: 2.5.5-vc14_2 [vc14] --> 2.7-vc14_0 conda-forge [vc14]
jpeg: 8d-vc14_2 [vc14] --> 9b-vc14_0 conda-forge [vc14]
libtiff: 4.0.6-vc14_2 [vc14] --> 4.0.6-vc14_7 conda-forge [vc14]
pillow: 3.4.2-py35_0 --> 4.0.0-py35_2 conda-forge
The following packages will be SUPERCEDED by a higher-priority channel:
conda: 4.3.11-py35_0 --> 4.2.13-py35_0 conda-forge
conda-env: 2.6.0-0 --> 2.6.0-0 conda-forge
qt: 4.8.7-vc14_9 [vc14] --> 4.8.7-vc14_6 conda-forge [vc14]
I decided not to proceed and instead tried pip install pillow. Since this command doesn't ask for confirmation the package was simply installed. Now when I type conda list I get:
Pillow 4.0.0 <pip>
pillow 3.4.2 py35_0
The package list of the PyCharm Interpreter now shows Pillow as being version 4.0.0 but conda update pillow still returns:
# All requested packages already installed.
pillow 3.4.2 py35_0
My questions are:
1) What should I rely on to keep all my packages up to date, without compatibility issues?
2) Why did conda install pillow: 4.0.0 return an error but conda install -c conda-forge pillow=4.0.0 didn't?
3) What do the * next to pillow 4.0.0 and python 3.5 in the list of dependencies mean?
4) Since now I have both Pillow 3.4.2 (in /anaconda3/pkgs) and Pillow 4.0.0 (in /anaconda3/lib/site-packages) which one would be used if I imported Pillow?
5) Does the superseding conda: 4.3.11-py35_0 --> 4.2.13-py35_0 conda-forge mean conda is getting downgraded?
6) What is the difference between the tags pip, py35_0, py35_4, np111py35_2, etc?
7) PyCharm tells me there's a version 2.9.5 of package Jinja2 but both normal conda and conda-forge only find 2.9.4. From which channel is PyCharm getting this information?


Ok, I can't answer all of your questions but here goes:
1) Conda defers to the "pain up front" approach for handling dependency/conflict resolution. You'll have to get all of your packages to play nicely together in the repo's/channels that you have available to even make a package or keep them in an environment together. You can try running it with --force or --no-deps to try getting it in but ..... that can cause issues for you in the future (I don't know if that would even work with the later versions of conda, it changes a lot). Simply keeping packages up to date, and up to latest, I would just use pip. Its come a long way in the last few years (https://glyph.twistedmatrix.com/2016/08/python-packaging.html)
2) I am not completely sure, I believe it would have something to do with providing an explicit non-url channel for conda to look at. Typically you pass it the URL to the conda-forge repo (I think, again we don't use conda-forge internally).
3) The * means you are ignoring the patch/build 4.0.0 == Major.Minor.Build. Likewise, 3.5* == any version of 3.5
4) I would import pillow in a terminal, and then print out the module to see where its getting pulled from, why guess?
5) pass (although I think so)
6)
pip : means you installed that package via pip. It will not be picked up if you do conda list --explicit
py35_0 : has a requirement / only available to envs / packages that use python 3.5
py35_4 : not sure (always forget that one)
np111py35_2 : requires python3.5 and also numpy 1.11 (I think *)
7) I tend to steer clear of pycharm, I believe that you can inspect the python interpreter that pycharm is pointing at to see what environment its in. Based on the root environment, you can do a conda info and get a list of all of the channels you are pointing to.
Note: if you are going to use conda, you may just want to add conda-forge to your channels list instead of passing the -c (but seeing how the other channels are organized should help you see how you should pass the -c flag)

Related

conda: what difference does it make if we set pip_interop_enabled=True?

There are many posts on this site which reference, typically in passing, the idea of setting pip_interop_enabled=True within some environment. This makes conda and pip3 somehow interact better, I am told. To be precise, people say conda will search PyPI for packages that don't exist in the main channels if this is true. They also say it's "experimental."
Here is conda's documentation about this. It notes that much of conda's behavior in recent versions has also improved even with pip_interop_enabled=False, leading to questions about what this setting even does.
Here is my question: in real terms, what does all of this mean?
Is the only difference that conda will search PyPI if this is True and not if it's False?
Are there other things that it does? For instance, if I need to install some package from pip, will conda know better not to clobber it if this setting is True?
What, to be precise, goes wrong if I set this to True? Are there known edge cases that somehow break things if this "experimental" setting is set to True?
Why would I ever not want to set this?

Not a PyPI Searching Feature
First, let's clarify: Conda will not "search PyPI" - that is not what the pip_interop_enabled configuration option adds. Rather, it enables the solver to allow a package already installed with pip to satisfy a dependency requirement of a Conda package. Note that the option is about Pip interoperability (as distinct from PyPI) and it doesn't matter whether the package was sourced from PyPI, GitHub, local, etc..
Example: scipy -> numpy
Let's consider a simple example to illustrate the behavior. Start with the following environment that has Python 3.10 and numpy installed from PyPI.
pip_interop.yaml
name: pip_interop
channels:
- conda-forge
dependencies:
- python=3.10
- pip
## PyPI packages
- pip:
- numpy
which we can create with
conda env create -n pip_interop -f pip_interop.yaml
and verify that the numpy is from PyPI:
$ conda list -n pip_interop numpy
# packages in environment at /Users/user/mambaforge/envs/pip_interop:
#
# Name Version Build Channel
numpy 1.24.2 pypi_0
Let's see what would happen installing scipy and in particular, how it satisfies its numpy dependency.
Installing without Pip interoperability
In default mode, we see the following behavior
$ conda install -n pip_interop scipy
Collecting package metadata (current_repodata.json): done
Solving environment: done
## Package Plan ##
environment location: /Users/user/mambaforge/envs/pip_interop
added / updated specs:
- scipy
The following packages will be downloaded:
package | build
---------------------------|-----------------
cryptography-39.0.1 | py310hdd0c95c_0 1.1 MB
numpy-1.24.2 | py310h788a5b3_0 6.1 MB
scipy-1.10.0 | py310h240c617_2 20.2 MB
------------------------------------------------------------
Total: 27.4 MB
The following NEW packages will be INSTALLED:
appdirs conda-forge/noarch::appdirs-1.4.4-pyh9f0ad1d_0
brotlipy conda-forge/osx-64::brotlipy-0.7.0-py310h90acd4f_1005
certifi conda-forge/noarch::certifi-2022.12.7-pyhd8ed1ab_0
cffi conda-forge/osx-64::cffi-1.15.1-py310ha78151a_3
charset-normalizer conda-forge/noarch::charset-normalizer-2.1.1-pyhd8ed1ab_0
cryptography conda-forge/osx-64::cryptography-39.0.1-py310hdd0c95c_0
idna conda-forge/noarch::idna-3.4-pyhd8ed1ab_0
libblas conda-forge/osx-64::libblas-3.9.0-16_osx64_openblas
libcblas conda-forge/osx-64::libcblas-3.9.0-16_osx64_openblas
libcxx conda-forge/osx-64::libcxx-14.0.6-hccf4f1f_0
libgfortran conda-forge/osx-64::libgfortran-5.0.0-11_3_0_h97931a8_27
libgfortran5 conda-forge/osx-64::libgfortran5-11.3.0-h082f757_27
liblapack conda-forge/osx-64::liblapack-3.9.0-16_osx64_openblas
libopenblas conda-forge/osx-64::libopenblas-0.3.21-openmp_h429af6e_3
llvm-openmp conda-forge/osx-64::llvm-openmp-15.0.7-h61d9ccf_0
numpy conda-forge/osx-64::numpy-1.24.2-py310h788a5b3_0
packaging conda-forge/noarch::packaging-23.0-pyhd8ed1ab_0
pooch conda-forge/noarch::pooch-1.6.0-pyhd8ed1ab_0
pycparser conda-forge/noarch::pycparser-2.21-pyhd8ed1ab_0
pyopenssl conda-forge/noarch::pyopenssl-23.0.0-pyhd8ed1ab_0
pysocks conda-forge/noarch::pysocks-1.7.1-pyha2e5f31_6
python_abi conda-forge/osx-64::python_abi-3.10-3_cp310
requests conda-forge/noarch::requests-2.28.2-pyhd8ed1ab_0
scipy conda-forge/osx-64::scipy-1.10.0-py310h240c617_2
urllib3 conda-forge/noarch::urllib3-1.26.14-pyhd8ed1ab_0
Proceed ([y]/n)?
Observe that despite numpy already being installed in the environment, Conda is proposing to replace it with a Conda version. That is, only considers the information in conda-meta/ to determine whether a package is installed and won't check the environment's lib/python3.10/site-packages/.
Installing with Pip interoperability
Now we try it with the pip_interop_enabled turned on:
$ CONDA_PIP_INTEROP_ENABLED=1 conda install -n foo scipy
Collecting package metadata (current_repodata.json): done
Solving environment: done
## Package Plan ##
environment location: /Users/user/mambaforge/envs/pip_interop
added / updated specs:
- scipy
The following packages will be downloaded:
package | build
---------------------------|-----------------
cryptography-39.0.1 | py310hdd0c95c_0 1.1 MB
scipy-1.10.0 | py310h240c617_2 20.2 MB
------------------------------------------------------------
Total: 21.3 MB
The following NEW packages will be INSTALLED:
appdirs conda-forge/noarch::appdirs-1.4.4-pyh9f0ad1d_0
brotlipy conda-forge/osx-64::brotlipy-0.7.0-py310h90acd4f_1005
certifi conda-forge/noarch::certifi-2022.12.7-pyhd8ed1ab_0
cffi conda-forge/osx-64::cffi-1.15.1-py310ha78151a_3
charset-normalizer conda-forge/noarch::charset-normalizer-2.1.1-pyhd8ed1ab_0
cryptography conda-forge/osx-64::cryptography-39.0.1-py310hdd0c95c_0
idna conda-forge/noarch::idna-3.4-pyhd8ed1ab_0
libblas conda-forge/osx-64::libblas-3.9.0-16_osx64_openblas
libcblas conda-forge/osx-64::libcblas-3.9.0-16_osx64_openblas
libcxx conda-forge/osx-64::libcxx-14.0.6-hccf4f1f_0
libgfortran conda-forge/osx-64::libgfortran-5.0.0-11_3_0_h97931a8_27
libgfortran5 conda-forge/osx-64::libgfortran5-11.3.0-h082f757_27
liblapack conda-forge/osx-64::liblapack-3.9.0-16_osx64_openblas
libopenblas conda-forge/osx-64::libopenblas-0.3.21-openmp_h429af6e_3
llvm-openmp conda-forge/osx-64::llvm-openmp-15.0.7-h61d9ccf_0
packaging conda-forge/noarch::packaging-23.0-pyhd8ed1ab_0
pooch conda-forge/noarch::pooch-1.6.0-pyhd8ed1ab_0
pycparser conda-forge/noarch::pycparser-2.21-pyhd8ed1ab_0
pyopenssl conda-forge/noarch::pyopenssl-23.0.0-pyhd8ed1ab_0
pysocks conda-forge/noarch::pysocks-1.7.1-pyha2e5f31_6
python_abi conda-forge/osx-64::python_abi-3.10-3_cp310
requests conda-forge/noarch::requests-2.28.2-pyhd8ed1ab_0
scipy conda-forge/osx-64::scipy-1.10.0-py310h240c617_2
urllib3 conda-forge/noarch::urllib3-1.26.14-pyhd8ed1ab_0
Proceed ([y]/n)?
Note that now the numpy is not proposed to be replaced and this is because the existing pip-installed version is consider able to satisfy the dependency.
Why is this experimental?
There may be multiple reasons why this remains experimental after several years. One important reason is that Conda only tests its package builds against Conda builds of the dependencies. So, it cannot guarantee that the packages are functionally exchangeable.
Furthermore, Conda packages often bring in non-Python dependencies. There has been a rise in wheel deployments, which is the PyPI approach to this, but isn't ubiquitous. There are still many "wrapper" packages out there where the PyPI version assumes some binary is on PATH, whereas the installation of the Conda package guarantees the binary is also installed.
Another important issue is that the PyPI-Conda name mapping is not well-defined. That is, the name of a package in PyPI may not correspond to its Conda package name. This can directly lead to cryptic issues when the names diverge. Specifically, Conda will not correctly recognize that a pip-installed package satisfies the requirement when the names don't match. Hence, the is some unexpected heterogeneity in how the interoperability applies.
Example: torch vs pytorch
In the Python ecosystem, the torch module is provided by the PyPI package torch. However, the package torch in PyPI goes by pytorch on Conda channels.
Here's how this can lead to inconsistent behavior. Let's begin with torch installed from PyPI:
pip_interop.yaml
name: pip_interop
channels:
- conda-forge
dependencies:
- python=3.10
- pip
## PyPI packages
- pip:
- torch
Creating with:
conda env create -n pip_interop -f pip_interop.yaml
Now if we install torchvision from Conda, even with the pip_interop_enabled on, we get:
$ CONDA_PIP_INTEROP_ENABLED=1 conda install -n pip_interop torchvision
Collecting package metadata (current_repodata.json): done
Solving environment: done
## Package Plan ##
environment location: /Users/user/mambaforge/envs/pip_interop
added / updated specs:
- torchvision
The following packages will be downloaded:
package | build
---------------------------|-----------------
cryptography-39.0.1 | py310hdd0c95c_0 1.1 MB
jpeg-9e | hb7f2c08_3 226 KB
libprotobuf-3.21.12 | hbc0c0cd_0 1.8 MB
mkl-2022.2.1 | h44ed08c_16952 113.1 MB
numpy-1.24.2 | py310h788a5b3_0 6.1 MB
pillow-9.4.0 | py310h306a057_1 44.1 MB
pytorch-1.13.1 |cpu_py310h2bbf33f_1 56.9 MB
sleef-3.5.1 | h6db0672_2 1.0 MB
torchvision-0.14.1 |cpu_py310hd5ee960_0 5.9 MB
------------------------------------------------------------
Total: 230.1 MB
The following NEW packages will be INSTALLED:
brotlipy conda-forge/osx-64::brotlipy-0.7.0-py310h90acd4f_1005
certifi conda-forge/noarch::certifi-2022.12.7-pyhd8ed1ab_0
cffi conda-forge/osx-64::cffi-1.15.1-py310ha78151a_3
charset-normalizer conda-forge/noarch::charset-normalizer-2.1.1-pyhd8ed1ab_0
cryptography conda-forge/osx-64::cryptography-39.0.1-py310hdd0c95c_0
freetype conda-forge/osx-64::freetype-2.12.1-h3f81eb7_1
idna conda-forge/noarch::idna-3.4-pyhd8ed1ab_0
jpeg conda-forge/osx-64::jpeg-9e-hb7f2c08_3
lcms2 conda-forge/osx-64::lcms2-2.14-h29502cd_1
lerc conda-forge/osx-64::lerc-4.0.0-hb486fe8_0
libblas conda-forge/osx-64::libblas-3.9.0-16_osx64_openblas
libcblas conda-forge/osx-64::libcblas-3.9.0-16_osx64_openblas
libcxx conda-forge/osx-64::libcxx-14.0.6-hccf4f1f_0
libdeflate conda-forge/osx-64::libdeflate-1.17-hac1461d_0
libgfortran conda-forge/osx-64::libgfortran-5.0.0-11_3_0_h97931a8_27
libgfortran5 conda-forge/osx-64::libgfortran5-11.3.0-h082f757_27
liblapack conda-forge/osx-64::liblapack-3.9.0-16_osx64_openblas
libopenblas conda-forge/osx-64::libopenblas-0.3.21-openmp_h429af6e_3
libpng conda-forge/osx-64::libpng-1.6.39-ha978bb4_0
libprotobuf conda-forge/osx-64::libprotobuf-3.21.12-hbc0c0cd_0
libtiff conda-forge/osx-64::libtiff-4.5.0-hee9004a_2
libwebp-base conda-forge/osx-64::libwebp-base-1.2.4-h775f41a_0
libxcb conda-forge/osx-64::libxcb-1.13-h0d85af4_1004
llvm-openmp conda-forge/osx-64::llvm-openmp-15.0.7-h61d9ccf_0
mkl conda-forge/osx-64::mkl-2022.2.1-h44ed08c_16952
numpy conda-forge/osx-64::numpy-1.24.2-py310h788a5b3_0
openjpeg conda-forge/osx-64::openjpeg-2.5.0-h13ac156_2
pillow conda-forge/osx-64::pillow-9.4.0-py310h306a057_1
pthread-stubs conda-forge/osx-64::pthread-stubs-0.4-hc929b4f_1001
pycparser conda-forge/noarch::pycparser-2.21-pyhd8ed1ab_0
pyopenssl conda-forge/noarch::pyopenssl-23.0.0-pyhd8ed1ab_0
pysocks conda-forge/noarch::pysocks-1.7.1-pyha2e5f31_6
python_abi conda-forge/osx-64::python_abi-3.10-3_cp310
pytorch conda-forge/osx-64::pytorch-1.13.1-cpu_py310h2bbf33f_1
requests conda-forge/noarch::requests-2.28.2-pyhd8ed1ab_0
sleef conda-forge/osx-64::sleef-3.5.1-h6db0672_2
tbb conda-forge/osx-64::tbb-2021.7.0-hb8565cd_1
torchvision conda-forge/osx-64::torchvision-0.14.1-cpu_py310hd5ee960_0
typing_extensions conda-forge/noarch::typing_extensions-4.4.0-pyha770c72_0
urllib3 conda-forge/noarch::urllib3-1.26.14-pyhd8ed1ab_0
xorg-libxau conda-forge/osx-64::xorg-libxau-1.0.9-h35c211d_0
xorg-libxdmcp conda-forge/osx-64::xorg-libxdmcp-1.1.3-h35c211d_0
zstd conda-forge/osx-64::zstd-1.5.2-hbc0c0cd_6
Proceed ([y]/n)?
That is, Conda still tries to install pytorch and this means that it will lead to clobbering of the existing torch package installed from PyPI. This has the potential to having residual files from the clobbered version of the package intermixed with the clobbering version.
Basically, this is undefined behavior and the Conda software may not give you any warning about potential problems.

basemap-data-hires not found despite being installed

I have the same problem as this post:
Declaring a var usable by another function using a import in a secondary script, but the answer does not work on my side.
For context: basemap and basemap-data-hires are installed, yet when using resolution = 'f' it triggers the following error:
OSError: Unable to open boundary dataset file. Only the 'crude' and 'low',
resolution datasets are installed by default.
If you are requesting an, 'intermediate', 'high' or 'full'
resolution dataset, you may need to download and install those
files separately with
conda install -c conda-forge basemap-data-hires.
Here is the conda list output:
C:\Users\AlxndrLhr>conda list
# packages in environment at C:\Users\AlxndrLhr\Anaconda3\envs\map:
#
# Name Version Build Channel
basemap 1.2.2 py39h689385a_5 conda-forge
basemap-data 1.3.2 pyhd8ed1ab_0 conda-forge
basemap-data-hires 1.3.2 pyhd8ed1ab_0 conda-forge
As you can see, basemap-data-hires is present. I tried installing it in the base environment of conda, didn't work either.

Before basemap 1.3.0, the library was packaged in conda-forge by splitting the heavy data files into a separate basemap-data-hires conda package (and whose files were installed in the share folder).
Since basemap 1.3.0, a complete reorganisation of the basemap package has been done upstream by splitting the library into basemap, basemap-data and basemap-data-hires. These three packages are Python packages and get installed in the corresponding Python site-packages folder. This new structuring is propagated to the conda-forge packages.
Your installation is mixing the old basemap conda package (pre-1.3.0) with the new basemap-data-hires conda package (post-1.3.0). You can solve the issue by pinning versions during installation, either the following to install the latest basemap:
conda install "basemap>=1.3.0" "basemap-data-hires>=1.3.0"
or the following to install the pre-1.3.0 version:
conda install "basemap==1.2.2" "basemap-data-hires==1.2.2"

how to install the arch package with anaconda?

I am trying to install the arch package https://pypi.org/project/arch/ using Anaconda.
The suggested install runs fine
(base) C:\Users\john>conda install arch-py -c conda-forge
Collecting package metadata (current_repodata.json): done
Solving environment: done
## Package Plan ##
environment location: C:\Users\john\anaconda3
added / updated specs:
- arch-py
The following NEW packages will be INSTALLED:
arch-py conda-forge/win-64::arch-py-4.18-py38h294d835_0
cython conda-forge/win-64::cython-0.29.22-py38h885f38d_0
icc_rt pkgs/main/win-64::icc_rt-2019.0.0-h0cc432a_1
patsy conda-forge/noarch::patsy-0.5.1-py_0
property-cached conda-forge/noarch::property-cached-1.6.4-py_0
scipy pkgs/main/win-64::scipy-1.6.1-py38h14eb087_0
statsmodels conda-forge/win-64::statsmodels-0.12.2-py38h347fdf6_0
The following packages will be UPDATED:
certifi pkgs/main::certifi-2020.12.5-py38haa9~ --> conda-forge::certifi-2020.12.5-py38haa244fe_1
The following packages will be SUPERSEDED by a higher-priority channel:
ca-certificates pkgs/main::ca-certificates-2021.1.19-~ --> conda-forge::ca-certificates-2020.12.5-h5b45459_0
conda pkgs/main::conda-4.9.2-py38haa95532_0 --> conda-forge::conda-4.9.2-py38haa244fe_0
openssl pkgs/main::openssl-1.1.1j-h2bbff1b_0 --> conda-forge::openssl-1.1.1j-h8ffe710_0
Proceed ([y]/n)? y
Preparing transaction: done
Verifying transaction: done
Executing transaction: done
(base) C:\Users\john>spyder
Unfortunately, I cannot import the package correctly when I start Spyder.
from arch import arch_model
ValueError: numpy.ndarray size changed, may indicate binary incompatibility. Expected 88 from C header, got 80 from PyObject
What should I do?
Thanks!

The package requires the most recent version of numpy. I tried to remove numpy and reinstall version 1.20.0 (the version needed) without success. Anaconda would stick to 1.19
Ultimately, I did what I should have done a long time ago. Download miniconda (not anaconda) and install only the packages I need. That way, no annoying conflicts when updating packages with conda!

Compiling scikit-image on Windows to run tests

I'm stumped. I'm developing some enhancements to scikit-image which are failing the automated build tests, probably due to rounding errors. I therefore need to get the automated tests running on my Windows system so that I can debug and work out what's wrong. I've so far tried two approaches, neither of which are working:
In my Anaconda Python 3.6 environment, when I try to run the automated tests, I am getting the following error:
RuntimeError: module compiled against API version 0xc but this version of numpy is 0xb
...which I have found reference to in other contexts, but have not been able to eliminate.
Since the automated test do run (but fail) on a Python 3.5-based system, I thought things might work if I tried a local Python 3.5 environment. Here, I am running into the issue that, despite being installed, the environment cannot find the MS C++ compiler cl.exe. It is installed in C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\ and is found and executed by my Python 3.6 environment, but my Python 3.5 environment doesn't find it despite me adding that directory to my PATH. I should add that my Python 3.6 environment finds it without the directory being added to the PATH. I understand that both Python 3.5 and 3.6 use MSVC 14.0.
I would prefer to fix the problem in my Python 3.6 environment if possible. Any assistance much appreciated.
Update
I have made a box-fresh Python 3.6 conda environment as follows:
conda create --name sk36 python=3.6
conda activate sk36
conda install scikit-image --only-deps
conda install cython
git clone https://github.com/scikit-image/scikit-image.git
cd scikit-image
pip install -e .
pytest skimage/feature
The specific error I am getting is as follows:
..\Anaconda3\lib\site-packages\py\_path\local.py:662: in pyimport
__import__(modname)
skimage\__init__.py:135: in <module>
from .data import data_dir
skimage\data\__init__.py:13: in <module>
from ..io import imread, use_plugin
skimage\io\__init__.py:7: in <module>
from .manage_plugins import *
skimage\io\manage_plugins.py:24: in <module>
from .collection import imread_collection_wrapper
skimage\io\collection.py:12: in <module>
from ..external.tifffile import TiffFile
skimage\external\tifffile\__init__.py:1: in <module>
from .tifffile import imsave, imread, imshow, TiffFile, TiffWriter, TiffSequence
skimage\external\tifffile\tifffile.py:292: in <module>
from . import _tifffile
E RuntimeError: module compiled against API version 0xc but this version of numpy is 0xb
...which appears to have something to do with tifffile. Since this package wasn't originally explicitly installed in my new environment, I tried installing various versions of it, including some which downgraded numpy and scipy. Still the same error as above.
Having done some more research it would appear that something is seeing numpy 1.13.x when in fact version 1.15.4 is installed. Here is the full output from conda list:
# Name Version Build Channel
blas 1.0 mkl anaconda
ca-certificates 2018.03.07 0 anaconda
certifi 2018.10.15 py36_0 anaconda
cloudpickle 0.6.1 py36_0 anaconda
cycler 0.10.0 py36h009560c_0 anaconda
cython 0.29 py36ha925a31_0 anaconda
dask-core 0.20.0 py36_0 anaconda
decorator 4.3.0 py36_0 anaconda
freetype 2.9.1 ha9979f8_1 anaconda
icc_rt 2017.0.4 h97af966_0 anaconda
icu 58.2 ha66f8fd_1 anaconda
imageio 2.4.1 py36_0 anaconda
intel-openmp 2019.0 118 anaconda
jpeg 9b hb83a4c4_2 anaconda
kiwisolver 1.0.1 py36h6538335_0 anaconda
libpng 1.6.35 h2a8f88b_0 anaconda
libtiff 4.0.9 h36446d0_2 anaconda
matplotlib 3.0.1 py36hc8f65d3_0 anaconda
mkl 2019.0 118 anaconda
mkl_fft 1.0.6 py36hdbbee80_0 anaconda
mkl_random 1.0.1 py36h77b88f5_1 anaconda
networkx 2.2 py36_1 anaconda
numpy 1.15.4 py36ha559c80_0 anaconda
numpy-base 1.15.4 py36h8128ebf_0 anaconda
olefile 0.46 py36_0 anaconda
openssl 1.0.2p hfa6e2cd_0 anaconda
package_has_been_revoked 1.0 0 enable_revoked
pillow 5.3.0 py36hdc69c19_0 anaconda
pip 18.1 py36_0 anaconda
pyparsing 2.3.0 py36_0 anaconda
pyqt 5.9.2 py36h6538335_2 anaconda
python 3.6.7 h33f27b4_1 anaconda
python-dateutil 2.7.5 py36_0 anaconda
pytz 2018.7 py36_0 anaconda
pywavelets 1.0.1 py36h8c2d366_0 anaconda
qt 5.9.6 vc14h1e9a669_2 anaconda
scikit-image 0.15.dev0 <pip>
scipy 1.1.0 py36h4f6bf74_1 anaconda
setuptools 40.5.0 py36_0 anaconda
sip 4.19.8 py36h6538335_0 anaconda
six 1.11.0 py36_1 anaconda
sqlite 3.25.2 hfa6e2cd_0 anaconda
tifffile 0.15.1 py36h452e1ab_1001 conda-forge
tk 8.6.8 hfa6e2cd_0 anaconda
toolz 0.9.0 py36_0 anaconda
tornado 5.1.1 py36hfa6e2cd_0 anaconda
vc 14.1 h21ff451_3 anaconda
vs2015_runtime 15.5.2 3 anaconda
wheel 0.32.2 py36_0 anaconda
wincertstore 0.2 py36h7fe50ca_0 anaconda
zlib 1.2.11 h8395fce_2 anaconda
Update 2
I've solved the problem for Python 3.6, and I think there's enough information above for the astute to be able to work out what was wrong. I'll put the solution in an answer below.
A cleanly built Python 3.5 environment can't find the compiler, so that issue still remains.

One approach you could try is to upgrade your numpy with
pip install numpy --upgrade
as described here: RuntimeError: module compiled against API version a but this version of numpy is 9
Otherwise (if for some reason you cannot upgrade numpy) I would suggest going with a virtual environment for scikit-image project. I just tried it on Windows 10 and was able to successfully execute tests. My steps (from cmd, inside the project folder):
conda uninstall scikit-image to remove any previously built/installed versions
conda -n scikit-image python=3.6 to create a virtual environment for this project (I used python 3.6, but you can change it to 3.5)
activate scikit-image activated the new virtual env
pip install -r requirements.txt -- installed dependencies (without this step I wasn't getting the dependencies for tests installed)
pip install -e .
pytest

It turns out that pytest wasn't actually installed in the correct environment, it was being invoked from base which did indeed have numpy 1.13.3 installed. Installing it in the cleanly built Python 3.6 environment solved the problem for Python 3.6 at least.

How do I update Anaconda?

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?

root is the old (pre-conda 4.4) name for the main environment; after conda 4.4, it was renamed to be base. source
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
(But this should be preceded by conda update -n base conda or simply conda update conda so you have the latest conda version installed)
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 base environment, selecting "Open Terminal":
This operation will only update the one selected environment (in this case, the base 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 base 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 then create a conda environment to hold them. Thanks to the conda package cache and the way file linking is used doing this is typically i) fast and ii) consumes very little additional disk space. E.g.
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 is pretty much exactly the same story, with the exception that you may not be able to update the base 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 base
conda update -n myenv --all

If you are trying to update your Anaconda version to a new one, you'll notice that running the new installer wouldn't work, as it complains the installation directory is non-empty.
So you should use conda to upgrade as detailed by the official docs:
conda update conda
conda update anaconda
In Windows, if you made a "for all users" installation, it might be necessary to run from an Anaconda prompt with Administrator privileges.
This prevents the error:
ERROR conda.core.link:_execute(502): An error occurred while uninstalling package 'defaults::conda-4.5.4-py36_0'.
PermissionError(13, 'Access is denied')

Open "command or conda prompt" and run:
conda update conda
conda update anaconda
It's a good idea to run both command twice (one after the other) to be sure that all the basic files are updated.
This should put you back on the latest 'releases', which contains packages that are selected by the people at Continuum to work well together.
If you want the last version of each package run (this can lead to an unstable environment):
conda update --all
Hope this helps.
Sources:
https://docs.anaconda.com/anaconda/install/update-version
https://github.com/conda/conda/issues/1414#issuecomment-119071154

This is what the official Anaconda documentation recommends:
conda update conda
conda install anaconda=2021.11
You can find the current and past version codes here.
The command will update to a specific release of the Anaconda meta-package.
I feel like (contrary to the claim made in the accepted answer) this is more what 95% of Anaconda users want imho: Upgrading to the latest version of the Anaconda meta-package (put together and tested by the Anaconda Distributors) and ignoring the update status of individual packages, which would be issued by conda update --all.

Open Anaconda cmd in base mode:
Then use conda update conda to update Anaconda.
You can then use conda update --all to update all the requirements for Anaconda:
conda update conda
conda update --all

Here's the best practice (in my humble experience). Selecting these four packages will also update all other dependencies to the appropriate versions that will help you keep your environment consistent. The latter is a common problem others have expressed in earlier responses. This solution doesn't need the terminal.

If you have trouble to get e.g. from 3.3.x to 4.x (conda update conda "does not work" to get to the next version) than try it more specific like so:
conda install conda=4.0 (or conda install anaconda=4.0)
https://www.anaconda.com/blog/developer-blog/anaconda-4-release/
You should know what you do, because conda could break due to the forced installation.
If you would like to get more flexibility/security you could use pkg-manager like nix(-pkgs) [with nix-shell] / NixOS.

Intro
This answer wraps up many answers and comments, it does not add new code, all credits go to the other answers, especially this answer that shows how to install the official release, fully in line with the docs.
In the following, the "docs" mean the official Anaconda documentation at Updating from older versions. It makes sense to read the docs, it is a short overview.
And since it will be used quite often, here is the definition of metapackage:
A metapackage is a very simple package that has at least a name and a
version. It need not have any dependencies or build steps.
Metapackages may list dependencies to several core, low-level
libraries and may contain links to software files that are
automatically downloaded when executed.
First step
As a first step before the anaconda install, you update conda:
conda update conda
Second step
As a second step, you have three choices: custom or official metapackage, or conda update --all.
1. Custom metapackage
If you are allowed to have the most recent custom metapackage (mind that this might not always be the best choice for standard packages with constrained dependencies), then you can use
conda install anaconda
Docs:
There is a special “custom” version of the Anaconda metapackage that
has all the package dependencies, but none of them are constrained.
The “custom” version is lower in version ordering than any actual
release number.
The starting point for the tests was the installed release 2021.05. After this, conda update anaconda and conda install anaconda both lead to the same new "downgraded custom version" of custom-py38_1, see at the bottom of the code blocks: version change of anaconda = 2021.05-py38_0 --> custom-py38_1. But using update leads to far more installed packages than install here:
update leads to more installation steps than install
(base) C:\WINDOWS\system32>conda update anaconda
Collecting package metadata (current_repodata.json): done
Solving environment: done
## Package Plan ##
environment location: C:\Users\toeft\anaconda3
added / updated specs:
- anaconda
The following packages will be downloaded:
package | build
---------------------------|-----------------
_anaconda_depends-2020.07 | py38_0 6 KB
anaconda-custom | py38_1 36 KB
anaconda-client-1.8.0 | py38haa95532_0 170 KB
anaconda-project-0.10.1 | pyhd3eb1b0_0 218 KB
astroid-2.6.6 | py38haa95532_0 314 KB
astropy-4.3.1 | py38hc7d831d_0 6.1 MB
attrs-21.2.0 | pyhd3eb1b0_0 46 KB
babel-2.9.1 | pyhd3eb1b0_0 5.5 MB
...
xlsxwriter-3.0.1 | pyhd3eb1b0_0 111 KB
xlwings-0.24.7 | py38haa95532_0 887 KB
zeromq-4.3.4 | hd77b12b_0 4.2 MB
zipp-3.5.0 | pyhd3eb1b0_0 13 KB
zope.interface-5.4.0 | py38h2bbff1b_0 305 KB
zstd-1.4.9 | h19a0ad4_0 478 KB
------------------------------------------------------------
Total: 218.2 MB
The following NEW packages will be INSTALLED:
_anaconda_depends pkgs/main/win-64::_anaconda_depends-2020.07-py38_0
cfitsio pkgs/main/win-64::cfitsio-3.470-he774522_6
charset-normalizer pkgs/main/noarch::charset-normalizer-2.0.4-pyhd3eb1b0_0
conda-pack pkgs/main/noarch::conda-pack-0.6.0-pyhd3eb1b0_0
debugpy pkgs/main/win-64::debugpy-1.4.1-py38hd77b12b_0
fonttools pkgs/main/noarch::fonttools-4.25.0-pyhd3eb1b0_0
gmpy2 pkgs/main/win-64::gmpy2-2.0.8-py38h7edee0f_3
libllvm9 pkgs/main/win-64::libllvm9-9.0.1-h21ff451_0
matplotlib-inline pkgs/main/noarch::matplotlib-inline-0.1.2-pyhd3eb1b0_2
mpc pkgs/main/win-64::mpc-1.1.0-h7edee0f_1
mpfr pkgs/main/win-64::mpfr-4.0.2-h62dcd97_1
mpir pkgs/main/win-64::mpir-3.0.0-hec2e145_1
munkres pkgs/main/noarch::munkres-1.1.4-py_0
The following packages will be REMOVED:
jupyter-packaging-0.7.12-pyhd3eb1b0_0
The following packages will be UPDATED:
anaconda-client 1.7.2-py38_0 --> 1.8.0-py38haa95532_0
anaconda-project 0.9.1-pyhd3eb1b0_1 --> 0.10.1-pyhd3eb1b0_0
astroid 2.5-py38haa95532_1 --> 2.6.6-py38haa95532_0
astropy 4.2.1-py38h2bbff1b_1 --> 4.3.1-py38hc7d831d_0
attrs 20.3.0-pyhd3eb1b0_0 --> 21.2.0-pyhd3eb1b0_0
babel 2.9.0-pyhd3eb1b0_0 --> 2.9.1-pyhd3eb1b0_0
bitarray 1.9.2-py38h2bbff1b_1 --> 2.3.0-py38h2bbff1b_1
bleach 3.3.0-pyhd3eb1b0_0 --> 4.0.0-pyhd3eb1b0_0
bokeh 2.3.2-py38haa95532_0 --> 2.3.3-py38haa95532_0
ca-certificates 2021.4.13-haa95532_1 --> 2021.7.5-haa95532_1
certifi 2020.12.5-py38haa95532_0 --> 2021.5.30-py38haa95532_0
cffi 1.14.5-py38hcd4344a_0 --> 1.14.6-py38h2bbff1b_0
click 7.1.2-pyhd3eb1b0_0 --> 8.0.1-pyhd3eb1b0_0
comtypes 1.1.9-py38haa95532_1002 --> 1.1.10-py38haa95532_1002
curl 7.71.1-h2a8f88b_1 --> 7.78.0-h86230a5_0
cython 0.29.23-py38hd77b12b_0 --> 0.29.24-py38hd77b12b_0
dask 2021.4.0-pyhd3eb1b0_0 --> 2021.8.1-pyhd3eb1b0_0
dask-core 2021.4.0-pyhd3eb1b0_0 --> 2021.8.1-pyhd3eb1b0_0
decorator 5.0.6-pyhd3eb1b0_0 --> 5.0.9-pyhd3eb1b0_0
distributed 2021.4.0-py38haa95532_0 --> 2021.8.1-py38haa95532_0
docutils 0.17-py38haa95532_1 --> 0.17.1-py38haa95532_1
et_xmlfile pkgs/main/noarch::et_xmlfile-1.0.1-py~ --> pkgs/main/win-64::et_xmlfile-1.1.0-py38haa95532_0
fsspec 0.9.0-pyhd3eb1b0_0 --> 2021.7.0-pyhd3eb1b0_0
gevent 21.1.2-py38h2bbff1b_1 --> 21.8.0-py38h2bbff1b_1
greenlet 1.0.0-py38hd77b12b_2 --> 1.1.1-py38hd77b12b_0
idna 2.10-pyhd3eb1b0_0 --> 3.2-pyhd3eb1b0_0
imagecodecs 2021.3.31-py38h5da4933_0 --> 2021.6.8-py38h5da4933_0
intel-openmp 2021.2.0-haa95532_616 --> 2021.3.0-haa95532_3372
ipykernel 5.3.4-py38h5ca1d4c_0 --> 6.2.0-py38haa95532_1
ipython 7.22.0-py38hd4e2768_0 --> 7.26.0-py38hd4e2768_0
isort 5.8.0-pyhd3eb1b0_0 --> 5.9.3-pyhd3eb1b0_0
itsdangerous 1.1.0-pyhd3eb1b0_0 --> 2.0.1-pyhd3eb1b0_0
jinja2 2.11.3-pyhd3eb1b0_0 --> 3.0.1-pyhd3eb1b0_0
json5 0.9.5-py_0 --> 0.9.6-pyhd3eb1b0_0
jupyterlab 3.0.14-pyhd3eb1b0_1 --> 3.1.7-pyhd3eb1b0_0
jupyterlab_server 2.4.0-pyhd3eb1b0_0 --> 2.7.1-pyhd3eb1b0_0
keyring 22.3.0-py38haa95532_0 --> 23.0.1-py38haa95532_0
krb5 1.18.2-hc04afaa_0 --> 1.19.2-h5b6d351_0
libcurl 7.71.1-h2a8f88b_1 --> 7.78.0-h86230a5_0
libxml2 2.9.10-hb89e7f3_3 --> 2.9.12-h0ad7f3c_0
lz4-c 1.9.3-h2bbff1b_0 --> 1.9.3-h2bbff1b_1
markupsafe 1.1.1-py38he774522_0 --> 2.0.1-py38h2bbff1b_0
matplotlib 3.3.4-py38haa95532_0 --> 3.4.2-py38haa95532_0
matplotlib-base 3.3.4-py38h49ac443_0 --> 3.4.2-py38h49ac443_0
mkl 2021.2.0-haa95532_296 --> 2021.3.0-haa95532_524
mkl-service 2.3.0-py38h2bbff1b_1 --> 2.4.0-py38h2bbff1b_0
mkl_random 1.2.1-py38hf11a4ad_2 --> 1.2.2-py38hf11a4ad_0
more-itertools 8.7.0-pyhd3eb1b0_0 --> 8.8.0-pyhd3eb1b0_0
nbconvert 6.0.7-py38_0 --> 6.1.0-py38haa95532_0
networkx 2.5-py_0 --> 2.6.2-pyhd3eb1b0_0
nltk 3.6.1-pyhd3eb1b0_0 --> 3.6.2-pyhd3eb1b0_0
notebook 6.3.0-py38haa95532_0 --> 6.4.3-py38haa95532_0
numpy 1.20.1-py38h34a8a5c_0 --> 1.20.3-py38ha4e8547_0
numpy-base 1.20.1-py38haf7ebc8_0 --> 1.20.3-py38hc2deb75_0
openjpeg 2.3.0-h5ec785f_1 --> 2.4.0-h4fc8c34_0
openssl 1.1.1k-h2bbff1b_0 --> 1.1.1l-h2bbff1b_0
packaging 20.9-pyhd3eb1b0_0 --> 21.0-pyhd3eb1b0_0
pandas 1.2.4-py38hd77b12b_0 --> 1.3.2-py38h6214cd6_0
path 15.1.2-py38haa95532_0 --> 16.0.0-py38haa95532_0
pathlib2 2.3.5-py38haa95532_2 --> 2.3.6-py38haa95532_2
pillow 8.2.0-py38h4fa10fc_0 --> 8.3.1-py38h4fa10fc_0
pkginfo 1.7.0-py38haa95532_0 --> 1.7.1-py38haa95532_0
prometheus_client 0.10.1-pyhd3eb1b0_0 --> 0.11.0-pyhd3eb1b0_0
pydocstyle 6.0.0-pyhd3eb1b0_0 --> 6.1.1-pyhd3eb1b0_0
pyerfa 1.7.3-py38h2bbff1b_0 --> 2.0.0-py38h2bbff1b_0
pygments 2.8.1-pyhd3eb1b0_0 --> 2.10.0-pyhd3eb1b0_0
pylint 2.7.4-py38haa95532_1 --> 2.9.6-py38haa95532_1
pyodbc 4.0.30-py38ha925a31_0 --> 4.0.31-py38hd77b12b_0
pytest 6.2.3-py38haa95532_2 --> 6.2.4-py38haa95532_2
python-dateutil 2.8.1-pyhd3eb1b0_0 --> 2.8.2-pyhd3eb1b0_0
pywin32 227-py38he774522_1 --> 228-py38hbaba5e8_1
pyzmq 20.0.0-py38hd77b12b_1 --> 22.2.1-py38hd77b12b_1
qtconsole 5.0.3-pyhd3eb1b0_0 --> 5.1.0-pyhd3eb1b0_0
qtpy 1.9.0-py_0 --> 1.10.0-pyhd3eb1b0_0
regex 2021.4.4-py38h2bbff1b_0 --> 2021.8.3-py38h2bbff1b_0
requests 2.25.1-pyhd3eb1b0_0 --> 2.26.0-pyhd3eb1b0_0
rope 0.18.0-py_0 --> 0.19.0-pyhd3eb1b0_0
scikit-learn 0.24.1-py38hf11a4ad_0 --> 0.24.2-py38hf11a4ad_1
seaborn 0.11.1-pyhd3eb1b0_0 --> 0.11.2-pyhd3eb1b0_0
singledispatch 3.6.1-pyhd3eb1b0_1001 --> 3.7.0-pyhd3eb1b0_1001
six pkgs/main/win-64::six-1.15.0-py38haa9~ --> pkgs/main/noarch::six-1.16.0-pyhd3eb1b0_0
sortedcontainers 2.3.0-pyhd3eb1b0_0 --> 2.4.0-pyhd3eb1b0_0
sphinx 4.0.1-pyhd3eb1b0_0 --> 4.0.2-pyhd3eb1b0_0
sphinxcontrib-htm~ 1.0.3-pyhd3eb1b0_0 --> 2.0.0-pyhd3eb1b0_0
sphinxcontrib-ser~ 1.1.4-pyhd3eb1b0_0 --> 1.1.5-pyhd3eb1b0_0
sqlalchemy 1.4.7-py38h2bbff1b_0 --> 1.4.22-py38h2bbff1b_0
sqlite 3.35.4-h2bbff1b_0 --> 3.36.0-h2bbff1b_0
testpath 0.4.4-pyhd3eb1b0_0 --> 0.5.0-pyhd3eb1b0_0
threadpoolctl 2.1.0-pyh5ca1d4c_0 --> 2.2.0-pyhbf3da8f_0
tifffile 2021.4.8-pyhd3eb1b0_2 --> 2021.7.2-pyhd3eb1b0_2
tqdm 4.59.0-pyhd3eb1b0_1 --> 4.62.1-pyhd3eb1b0_1
typed-ast 1.4.2-py38h2bbff1b_1 --> 1.4.3-py38h2bbff1b_1
typing_extensions 3.7.4.3-pyha847dfd_0 --> 3.10.0.0-pyh06a4308_0
urllib3 1.26.4-pyhd3eb1b0_0 --> 1.26.6-pyhd3eb1b0_1
wheel 0.36.2-pyhd3eb1b0_0 --> 0.37.0-pyhd3eb1b0_0
xlsxwriter 1.3.8-pyhd3eb1b0_0 --> 3.0.1-pyhd3eb1b0_0
xlwings 0.23.0-py38haa95532_0 --> 0.24.7-py38haa95532_0
zeromq 4.3.3-ha925a31_3 --> 4.3.4-hd77b12b_0
zipp 3.4.1-pyhd3eb1b0_0 --> 3.5.0-pyhd3eb1b0_0
zope.interface 5.3.0-py38h2bbff1b_0 --> 5.4.0-py38h2bbff1b_0
zstd 1.4.5-h04227a9_0 --> 1.4.9-h19a0ad4_0
The following packages will be DOWNGRADED:
anaconda 2021.05-py38_0 --> custom-py38_1
install leads to less installation steps than update:
(base) C:\WINDOWS\system32>conda install anaconda
Collecting package metadata (current_repodata.json): done
Solving environment: done
## Package Plan ##
environment location: C:\Users\toeft\anaconda3
added / updated specs:
- anaconda
The following packages will be downloaded:
package | build
---------------------------|-----------------
_anaconda_depends-2020.07 | py38_0 6 KB
anaconda-custom | py38_1 36 KB
ca-certificates-2021.7.5 | haa95532_1 113 KB
certifi-2021.5.30 | py38haa95532_0 140 KB
gmpy2-2.0.8 | py38h7edee0f_3 145 KB
libllvm9-9.0.1 | h21ff451_0 61 KB
mpc-1.1.0 | h7edee0f_1 260 KB
mpfr-4.0.2 | h62dcd97_1 1.5 MB
mpir-3.0.0 | hec2e145_1 1.3 MB
openssl-1.1.1l | h2bbff1b_0 4.8 MB
------------------------------------------------------------
Total: 8.4 MB
The following NEW packages will be INSTALLED:
_anaconda_depends pkgs/main/win-64::_anaconda_depends-2020.07-py38_0
gmpy2 pkgs/main/win-64::gmpy2-2.0.8-py38h7edee0f_3
libllvm9 pkgs/main/win-64::libllvm9-9.0.1-h21ff451_0
mpc pkgs/main/win-64::mpc-1.1.0-h7edee0f_1
mpfr pkgs/main/win-64::mpfr-4.0.2-h62dcd97_1
mpir pkgs/main/win-64::mpir-3.0.0-hec2e145_1
The following packages will be UPDATED:
ca-certificates 2021.4.13-haa95532_1 --> 2021.7.5-haa95532_1
certifi 2020.12.5-py38haa95532_0 --> 2021.5.30-py38haa95532_0
openssl 1.1.1k-h2bbff1b_0 --> 1.1.1l-h2bbff1b_0
The following packages will be DOWNGRADED:
anaconda 2021.05-py38_0 --> custom-py38_1
2. Official metapackage (= release)
In the following code snippets, update and install lead to the same results. I use install like in the docs.
If you do not want to install a custom version of the metapackage but rather need the most recent official release, install with
conda install anaconda=VersionNumber
Find the VersionNumber
At the time of writing, in 09/2021, the latest available release (Anaconda individual edition) is
conda install anaconda=2021.05
But how to get hold of this VersionNumber?
Have a look at the Anaconda Release notes of the individual edition. If you need an older version, you need to scroll down that page, for example to find 2020.11. The most recent is always on top of the page. If you use a commercial edition, you need to check other release notes.
Thus, something like the 2021.05 version code is the latest release shortcut that you need to find. You can also find the full version name of your OS like for example Anaconda3-2021.05-Windows-x86_64.exe in the list of available Anaconda versions that is directly linked in the docs. It is sorted by name and date, thus, you need to search for the year like "YYYY-MM" / "YYYY-" or scroll through the whole list to find the most recent versions:
For the example of Windows 10 64 bit, the command could as well be:
conda update anaconda=Anaconda3-2021.05-Windows-x86_64.exe
If you install a release after having installed the most recent custom metapackage, you will see some packages to be removed and quite many to be downgraded slightly. This is because the release is slightly back in time, but therefore also fully trusted.
Docs:
conda update anaconda=VersionNumber grabs the specific release of the
Anaconda metapackage, for example conda update anaconda=2019.10. That
metapackage represents a pinned state that has undergone testing as a
collection.
3. Do not use conda update --all
As to the docs (last sentence of the following quote below), installing the custom (= most recent) metapackage of 2019.07 can be done as well by running
conda update --all
and if you have virtual environments, you need:
conda update -n myenv --all
YET: This was probably an exception for 2019.07. It does not seem to hold for higher metapackage versions. I checked the differences of conda update --all against conda update anaconda on a row to row comparison (see below, after the quote). Although they seem like twins at first, there were enough small differences to say that you should keep your hands off conda update --all since possible conflicting constraints are even mentioned in the docs.
Docs:
conda update --all will unpin everything. This updates all packages in
the current environment to the latest version. In doing so, it drops
all the version constraints from the history and tries to make
everything as new as it can.
This has the same behavior with removing packages. If any packages are
orphaned by an update, they are removed. conda update --all may not be
able to make everything the latest versions because you may have
conflicting constraints in your environment.
With Anaconda 2019.07’s newer Anaconda metapackage, conda update --all
will make the metapackage go to the custom version in order to update
other specs.
The whole output, put against each other on a row to row base, reveals the following remaining row differences. This proves that conda update --all is not just the custom metapackage:
conda update --all output lines not found in conda update anaconda
(base) C:\WINDOWS\system32>conda update --all
The following packages will be downloaded:
anaconda-navigator-2.0.4 | py38_0 5.2 MB
conda-build-3.21.4 | py38haa95532_0 552 KB
conda-content-trust-0.1.1 | pyhd3eb1b0_0 56 KB
conda-repo-cli-1.0.4 | pyhd3eb1b0_0 47 KB
conda-token-0.3.0 | pyhd3eb1b0_0 10 KB
menuinst-1.4.17 | py38h59b6b97_0 96 KB
python-3.8.11 | h6244533_1 16.0 MB
Total: 224.8 MB
The following NEW packages will be INSTALLED:
conda-content-tru~ pkgs/main/noarch::conda-content-trust-0.1.1-pyhd3eb1b0_0
conda-repo-cli pkgs/main/noarch::conda-repo-cli-1.0.4-pyhd3eb1b0_0
conda-token pkgs/main/noarch::conda-token-0.3.0-pyhd3eb1b0_0
The following packages will be UPDATED:
anaconda-navigator 1.10.0-py38_0 --> 2.0.4-py38_0
conda-build 3.20.5-py38_1 --> 3.21.4-py38haa95532_0
et_xmlfile pkgs/main/noarch::et_xmlfile-1.0.1-py~ --> pkgs/main/win-64::et_xmlfile-1.1.0-py38haa95532_0
menuinst 1.4.16-py38he774522_1 --> 1.4.17-py38h59b6b97_0
python 3.8.8-hdbf39b2_5 --> 3.8.11-h6244533_1
six pkgs/main/win-64::six-1.15.0-py38haa9~ --> pkgs/main/noarch::six-1.16.0-pyhd3eb1b0_0
sphinxcontrib-htm~ 1.0.3-pyhd3eb1b0_0 --> 2.0.0-pyhd3eb1b0_0
sphinxcontrib-ser~ 1.1.4-pyhd3eb1b0_0 --> 1.1.5-pyhd3eb1b0_0
conda update anaconda output lines not found in conda update --all
(base) C:\WINDOWS\system32>conda update anaconda
added / updated specs:
- anaconda
The following packages will be downloaded:
cfitsio-3.470 | he774522_6 512 KB
imagecodecs-2021.6.8 | py38h5da4933_0 6.1 MB
jinja2-3.0.1 | pyhd3eb1b0_0 110 KB
tifffile-2021.7.2 | pyhd3eb1b0_2 135 KB
typed-ast-1.4.3 | py38h2bbff1b_1 135 KB
Total: 209.8 MB
The following NEW packages will be INSTALLED:
cfitsio pkgs/main/win-64::cfitsio-3.470-he774522_6
The following packages will be UPDATED:
et_xmlfile pkgs/main/noarch::et_xmlfile-1.0.1-py~ --> pkgs/main/win-64::et_xmlfile-1.1.0-py38haa95532_0
imagecodecs 2021.3.31-py38h5da4933_0 --> 2021.6.8-py38h5da4933_0
jinja2 2.11.3-pyhd3eb1b0_0 --> 3.0.1-pyhd3eb1b0_0
six pkgs/main/win-64::six-1.15.0-py38haa9~ --> pkgs/main/noarch::six-1.16.0-pyhd3eb1b0_0
sphinxcontrib-htm~ 1.0.3-pyhd3eb1b0_0 --> 2.0.0-pyhd3eb1b0_0
sphinxcontrib-ser~ 1.1.4-pyhd3eb1b0_0 --> 1.1.5-pyhd3eb1b0_0
tifffile 2021.4.8-pyhd3eb1b0_2 --> 2021.7.2-pyhd3eb1b0_2
typed-ast 1.4.2-py38h2bbff1b_1 --> 1.4.3-py38h2bbff1b_1
Therefore, conda update --all is not recommended, better stick to the custom metapackage if you need the highest possible update, or take the official metapackage if you are fine with a lag of a couple of months and a collection of packages without any conflicts is most important (for example, if you are in a production environment).
Result: Which to install: official or custom metapackage?
Some answers or comments say that the custom metapackage install might need to be run twice to get to a proper state. I cannot confirm this (tested with conda install anaconda and conda update anaconda, but I am also in a fresh Python installation). This is still a hint that it might be more stable to install the most recent official metapackage (= release, conda install anaconda=VersionNumber = conda update anaconda=VersionNumber) which can have a lag of some months.
On the other hand, the custom metapackage (the most recent trusted package collection) might be good if you want the most recent versions available. Then run conda install anaconda or the even stronger command conda update anaconda.
This is also the way to update Spyder:
They do not even use conda update conda before conda update anaconda, the latter seems enough.
Small "proof": I used conda update conda at first, and after that, conda update anaconda had nothing to do anymore, conda update conda had done all or the tasks.
conda update anaconda
Collecting package metadata (current_repodata.json): done Solving environment: done
# All requested packages already installed.
That again sounds as if both commands are made the same now, perhaps they have not been the same only in the past.
The choice is up to you, it depends on how urgently you need to be up-to-date with some packages. Just start the installer to see what would happen, you can still enter n to cancel the installation. I am going to take
conda update anaconda
without conda update conda.
And do not take conda update --all unless you need the most recent update of some package, for example as a requirement for another package to be installed. I ran into that when testing --all, only after that, a new tensorflow add-on was suggested for download, but not after the other commands. Normally, you will not need to be up to date on the point, therefore do not use --all.

Yet, another answer:
conda update -n base conda -c anaconda
where -c your preferred channel or simply leave out.
copied from here

I'm using Windows 10. The following updates everything and also installs some new packages, including a Python update (for me it was 3.7.3).
At the shell, try the following (be sure to change where your Anaconda 3 Data is installed). It takes some time to update everything.
conda update --prefix X:\XXXXData\Anaconda3 anaconda

To update your installed version to the latest version, say 2019.07, run:
conda install anaconda=2019.07
In most cases, this method can meet your needs and avoid dependency problems.

On Mac, open a terminal and run the following two commands.
conda update conda
conda update anaconda
Make sure to run each command multiple times to update to the current version.

Use:
conda create -n py37 -c anaconda anaconda=5.3.1
conda env export -n py37 --file env.yaml
Locate the env.yaml file in C:\Windows\System32 and run the cmd as administrator:
conda env update -n root -f env.yaml
Then it works!

I also tried updating anaconda using conda install -n base anaconda=2022.10, but this resulted in conflicts indicating that my python version was too low (3.6).
I eventually managed to update using the following command:
conda install -n base anaconda=2022.10 python=3.8
The latest anaconda version code can be found in the release notes.
(In between I also reset my base environment using conda install --rev 0, not sure this was necessary though. In any case, be aware of possible consequences when trying this!)

Categories

Resources