Develop Reference

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.

conda conflicts do not make sense when installing graphviz (UnsatisfiableError) [duplicate]

I am attempting to create a conda environment with 3 packages and a specific python version and get the following output:
$ conda create -n testing_junk -y instrain awscli samtools python=3.8
Collecting package metadata (current_repodata.json): done
Solving environment: failed with repodata from current_repodata.json, will retry with next repodata source.
Collecting package metadata (repodata.json): done
Solving environment: |
Found conflicts! Looking for incompatible packages.
This can take several minutes. Press CTRL-C to abort.
failed \
UnsatisfiableError: The following specifications were found to be incompatible with each other:
Output in format: Requested package -> Available versions
Package ncurses conflicts for:
python=3.8 -> ncurses[version='>=6.1,<6.2.0a0|>=6.2,<7.0a0|>=6.1,<7.0a0']
awscli -> python[version='>=3.8,<3.9.0a0'] -> ncurses[version='5.9.*|5.9|>=6.1,<6.2.0a0|>=6.2,<7.0a0|>=6.1,<7.0a0|>=6.0,<7.0a0|6.0.*']
instrain -> python[version='>=3.4'] -> ncurses[version='5.9.*|5.9|>=6.1,<6.2.0a0|>=6.2,<7.0a0|>=6.1,<7.0a0|>=6.0,<7.0a0|6.0.*']
python=3.8 -> readline[version='>=7.0,<8.0a0'] -> ncurses[version='5.9.*|>=6.0,<7.0a0|6.0.*']
samtools -> ncurses[version='5.9|5.9.*|>=5.9,<5.10.0a0|>=6.1,<6.2.0a0']
Package python conflicts for:
awscli -> python[version='2.7.*|3.5.*|3.6.*|>=2.7,<2.8.0a0|>=3.6,<3.7.0a0|>=3.7,<3.8.0a0|>=3.8,<3.9.0a0|>=3.5,<3.6.0a0|3.4.*']
python=3.8
instrain -> biopython -> python[version='2.7.*|3.5.*|3.6.*|>=2.7,<2.8.0a0|>=3.6,<3.7.0a0|>=3.8,<3.9.0a0|>=3.7,<3.8.0a0|>=3.5,<3.6.0a0|3.4.*|>3|>=3.5|<3.0.0|>=3.6']
instrain -> python[version='>=3.4']
awscli -> python_abi=3.8[build=*_cp38] -> python[version='3.7.*|3.8.*']
Package ca-certificates conflicts for:
samtools -> openssl[version='>=1.1.1a,<1.1.2a'] -> ca-certificates
python=3.8 -> openssl[version='>=1.1.1g,<1.1.2a'] -> ca-certificates
awscli -> python[version='>=2.7,<2.8.0a0'] -> ca-certificates
Package setuptools conflicts for:
python=3.8 -> pip -> setuptools
instrain -> matplotlib-base -> setuptools[version='>=40.0']
Package libgcc-ng conflicts for:
samtools -> ncurses[version='>=6.1,<6.2.0a0'] -> libgcc-ng[version='>=7.2.0']
samtools -> libgcc-ng[version='>=4.9|>=7.3.0']
Package pypy3.6 conflicts for:
instrain -> numpy -> pypy3.6[version='7.3.0.*|7.3.1.*|>=7.3.1']
awscli -> python[version='>=3.6,<3.7.0a0'] -> pypy3.6[version='7.3.*|7.3.0.*|7.3.1.*']
Package bzip2 conflicts for:
samtools -> bzip2[version='1.0.*|>=1.0.6,<2.0a0|>=1.0.8,<2.0a0']
instrain -> pysam -> bzip2[version='>=1.0.6,<2.0a0|>=1.0.8,<2.0a0']
awscli -> python[version='>=3.7,<3.8.0a0'] -> bzip2[version='>=1.0.6,<2.0a0|>=1.0.8,<2.0a0']
Package zlib conflicts for:
samtools -> zlib[version='1.2.11.*|>=1.2.11,<1.3.0a0|1.2.8.*|1.2.8']
samtools -> curl[version='>=7.59.0,<8.0a0'] -> zlib[version='1.2.*|1.2.11']
Package samtools conflicts for:
samtools
instrain -> pysam -> samtools[version='1.3|1.3.1.*|1.3.1|1.5.*|1.6.*|1.7|1.7.*|1.9.*|>=1.4.1|>=1.4.1,<1.5|>=1.4,<1.5|>=1.3,<1.4|>=1.3']
Package openssl conflicts for:
samtools -> curl[version='>=7.59.0,<8.0a0'] -> openssl[version='1.0.*|>=1.0.2o,<1.0.3a|>=1.0.2m,<1.0.3a']
samtools -> openssl[version='>=1.0.2p,<1.0.3a|>=1.0.2r,<1.0.3a|>=1.1.1a,<1.1.2a']
Package _libgcc_mutex conflicts for:
samtools -> libgcc-ng[version='>=7.3.0'] -> _libgcc_mutex[version='*|0.1',build='main|conda_forge']
python=3.8 -> libgcc-ng[version='>=7.5.0'] -> _libgcc_mutex[version='*|0.1',build='main|conda_forge']The following specifications were found to be incompatible with your CUDA driver:
- feature:/linux-64::__cuda==10.2=0
- feature:|#/linux-64::__cuda==10.2=0
Your installed CUDA driver is: 10.2
I understand that there is something about the packages that conflict with each other, but I'm unable to interpret this output to understand what the problem is.
For example, in looking at the first block of conflicts (related to ncurses), shouldn't version 6.1 satisfy all requirements listed?
Additionally, for the block about package setuptools, I don't see any problem at all?
Any insight into how to interpret these conflicts so that I can attempt to address them would be much appreciated.

Some Practical Advice
#Quantum7's answer gives a fine literal interpretation of Conda's conflict reporting. However, I wanted to offer a more practical take, which is that this "feature" from Conda is too non-specific to be useful in most non-trivial environments. And sometimes it won't even include the underlying conflict. Don't waste your time with it!
Conda's Conflict Reporting is Often Not Helpful
On the face of it, Conda attempts to report all possible sources of conflict. That is, all sets of paths in the dependency graph that begin from the explicit specifications and end in the same package. This amounts to most of what is reported being innocuous and frankly distracting. For example, the zlib "conflicts":
Package zlib conflicts for:
samtools -> zlib[version='1.2.11.*|>=1.2.11,<1.3.0a0|1.2.8.*|1.2.8']
samtools -> curl[version='>=7.59.0,<8.0a0'] -> zlib[version='1.2.*|1.2.11']
Since samtools depends on zlib both directly and indirectly (mediated through curl), this comes up as two alternate paths that lead to constraints. The problem is that the intersection of the final constraints are not empty, such that there is nothing incompatible here.
Furthermore, there are cases where none of what is reported is in conflict (e.g., this question or this one), which means parsing through the output could be a complete waste of time.
Try Mamba
Instead, if one is actually concerned with resolving conflicts, I find Mamba to be more effective to work with, both in speed and precision.
# install mamba
conda install -n base conda-forge::mamba
# use 'mamba' just like 'conda'
mamba create -n foo instrain awscli samtools python=3.8
Unfortunately, this example simply works now. However, there are other questions where Conda and Mamba unsatisfiability reporting is compared, e.g., this question.

The package version specification is described here, but the important parts are:
, represents AND and has the highest precedence
| represents OR and has second precedence
Alpha versions (e.g. '6.2.0a0') are used in upper bounds since they are the first possible release from that version
As an example, consider the first line of the ncurses group:
python=3.8 -> ncurses[version='>=6.1,<6.2.0a0|>=6.2,<7.0a0|>=6.1,<7.0a0']
This indicates that your requested python=3.8 depends on ncurses with the following versions:
>=6.1,<6.2.0a0 version 6.1*
OR >=6.2,<7.0a0 version 6.2*
OR >=6.1,<7.0a0 (redundantly) at least 6.1 but not as high as 7.0
The lists are difficult to read since they include many unnecessary constraints. However, also didn't see any real conflicts with your versions. Not trusting my own ability to check package specifications, I found the conda package that does it directly:
>>> from conda.models import version as cv
>>> cv.VersionSpec(">=6.1,<6.2.0a0|>=6.2,<7.0a0|>=6.1,<7.0a0").match("6.1")
True
Running this on all the conflicts you reported, I was a able to find versions that satisfied all the stated version requirements: https://gist.github.com/sbliven/aab43e1f0bce1f4ac63aaaaa718df0b3
The only part I can't test is the cuda part, but it does look like you have a graphics card that supports CUDA 10.2.
When I started this answer I was preparing an explanation about how SAT solvers like the one used in conda add constraints iteratively and how that could lead to seemingly valid constraints being output as conflicts. However, there should always be some conflict, so I think your issue must lie elsewhere
Since samtools seems to have been removed from conda-forge I'm unable to reproduce the example myself, so I'm left confused about the exact error you're seeing. Hopefully understanding the version strings helps in the future.
Edit: Of course, samtools is from bioconda not conda-forge! The following command worked for me:
conda create -n testing_junk -c bioconda -y instrain awscli samtools python=3.8
It resolved to these package versions (maybe something was fixed since your question posted):
The following packages will be downloaded:
package | build
---------------------------|-----------------
asteval-0.9.16 | pyh5ca1d4c_0 18 KB conda-forge
awscli-1.18.221 | py38h50d1736_0 1.8 MB conda-forge
biopython-1.74 | py38h0b31af3_0 2.5 MB conda-forge
blas-2.14 | openblas 10 KB conda-forge
boost-1.70.0 | py38hbf1eeb5_1 347 KB conda-forge
boost-cpp-1.70.0 | hef959ae_3 18.9 MB conda-forge
botocore-1.19.61 | pyhd8ed1ab_0 4.5 MB conda-forge
brotlipy-0.7.0 |py38h5406a74_1001 357 KB conda-forge
c-ares-1.11.0 | 0 73 KB bioconda
capnproto-0.6.1 | h0ceac7d_2 2.4 MB conda-forge
cffi-1.14.4 | py38h979bc6b_1 219 KB conda-forge
colorama-0.4.3 | py_0 17 KB conda-forge
cryptography-3.3.1 | py38h6b4ec92_1 614 KB conda-forge
docutils-0.15.2 | py38h50d1736_1 739 KB conda-forge
drep-3.0.0 | py_2 59 KB bioconda
fastani-1.32 | he69ab0f_0 151 KB bioconda
future-0.18.2 | py38h50d1736_3 715 KB conda-forge
hdf5-1.10.6 |nompi_h34ad4e8_1111 3.0 MB conda-forge
htslib-1.11 | h422799e_1 1.5 MB bioconda
idna-3.1 | pyhd3deb0d_0 52 KB conda-forge
instrain-1.4.0 | py_0 380 KB bioconda
jmespath-0.10.0 | pyh9f0ad1d_0 21 KB conda-forge
joblib-1.0.0 | pyhd8ed1ab_0 206 KB conda-forge
kiwisolver-1.3.1 | py38hd9c93a9_1 57 KB conda-forge
libblas-3.8.0 | 14_openblas 10 KB conda-forge
libcblas-3.8.0 | 14_openblas 10 KB conda-forge
libdeflate-1.6 | h0b31af3_0 61 KB conda-forge
liblapack-3.8.0 | 14_openblas 10 KB conda-forge
liblapacke-3.8.0 | 14_openblas 10 KB conda-forge
libnghttp2-1.41.0 | h8a08a2b_1 736 KB conda-forge
libopenblas-0.3.7 | h3d69b6c_4 8.2 MB conda-forge
llvm-openmp-8.0.1 | h770b8ee_0 253 KB conda-forge
llvmlite-0.34.0 | py38h3707e27_2 247 KB conda-forge
lmfit-1.0.1 | py_1 69 KB conda-forge
mash-2.2.2 | h194473e_2 449 KB bioconda
matplotlib-base-3.3.4 | py38hb24f337_0 6.8 MB conda-forge
mummer4-4.0.0rc1 | pl526h4a8c4bd_0 699 KB bioconda
numba-0.51.2 | py38h6be0db6_0 3.5 MB conda-forge
openmp-8.0.1 | 0 8 KB conda-forge
pandas-1.2.1 | py38he9f00de_0 10.6 MB conda-forge
pillow-8.1.0 | py38hc1d52f7_1 646 KB conda-forge
pluggy-0.13.1 | py38h50d1736_4 29 KB conda-forge
prodigal-2.6.3 | h01d97ff_2 397 KB bioconda
psutil-5.8.0 | py38h5406a74_1 350 KB conda-forge
pyasn1-0.4.8 | py_0 53 KB conda-forge
pysam-0.16.0.1 | py38hb3e8b06_1 2.1 MB bioconda
pysocks-1.7.1 | py38h50d1736_3 27 KB conda-forge
pytest-6.2.2 | py38h50d1736_0 432 KB conda-forge
pyyaml-5.3.1 | py38h5406a74_2 173 KB conda-forge
rsa-4.4.1 | pyh9f0ad1d_0 27 KB conda-forge
s3transfer-0.3.4 | pyhd8ed1ab_0 51 KB conda-forge
samtools-1.11 | h725deca_0 381 KB bioconda
scikit-learn-0.22.1 | py38hebd9d1a_0 4.7 MB
scipy-1.5.3 | py38h352ea5d_0 19.1 MB conda-forge
seaborn-0.11.1 | hd8ed1ab_1 4 KB conda-forge
seaborn-base-0.11.1 | pyhd8ed1ab_1 217 KB conda-forge
statsmodels-0.12.1 | py38hc7193ba_2 10.5 MB conda-forge
tornado-6.1 | py38h5406a74_1 643 KB conda-forge
uncertainties-3.1.5 | pyhd8ed1ab_0 75 KB conda-forge
------------------------------------------------------------
Total: 110.1 MB

sometimes packages have conflicts because are download from different chanels. Try this in terminal:
conda config --add channels conda-forge # add conda-forge channel
conda config --set channel_priority strict # set priority of channel
then try:
conda create -n testing_junk -c conda-forge python=3.8 -y instrain awscli samtools
I hope you find it useful

Why does conda want to update unrelated packages when I want to remove just one?

Windows 10
conda 4.9.2 (via miniconda)
I installed a single package that did not require any other dependencies to be installed anew or upgraded. Once I realised that I had installed an unsuitable version of the package, I went to remove it, and this is the screen I was presented with:
(pydata) PS C:\Users\Navneeth> conda remove xlrd
Collecting package metadata (repodata.json): done
Solving environment: |
Warning: 2 possible package resolutions (only showing differing packages):
- defaults/win-64::libtiff-4.1.0-h56a325e_1, defaults/win-64::zstd-1.4.9-h19a0ad4_0
- defaults/win-64::libtiff-4.2.0-hd0e1b90_0, defaults/win-64::zstd-1.4.5-h04227a9done
## Package Plan ##
environment location: C:\Users\Navneeth\Miniconda3\envs\pydata
removed specs:
- xlrd
The following packages will be downloaded:
package | build
---------------------------|-----------------
decorator-5.0.3 | pyhd3eb1b0_0 12 KB
importlib-metadata-3.7.3 | py38haa95532_1 31 KB
importlib_metadata-3.7.3 | hd3eb1b0_1 11 KB
ipython-7.22.0 | py38hd4e2768_0 998 KB
jupyter_client-6.1.12 | pyhd3eb1b0_0 88 KB
libtiff-4.1.0 | h56a325e_1 739 KB
nbformat-5.1.3 | pyhd3eb1b0_0 44 KB
notebook-6.3.0 | py38haa95532_0 4.4 MB
pandoc-2.12 | haa95532_0 13.2 MB
parso-0.8.2 | pyhd3eb1b0_0 69 KB
pillow-8.2.0 | py38h4fa10fc_0 671 KB
prometheus_client-0.10.0 | pyhd3eb1b0_0 46 KB
prompt-toolkit-3.0.17 | pyh06a4308_0 256 KB
terminado-0.9.4 | py38haa95532_0 26 KB
zipp-3.4.1 | pyhd3eb1b0_0 15 KB
zstd-1.4.9 | h19a0ad4_0 478 KB
------------------------------------------------------------
Total: 21.0 MB
The following packages will be REMOVED:
xlrd-2.0.1-pyhd3eb1b0_0
The following packages will be UPDATED:
decorator 4.4.2-pyhd3eb1b0_0 --> 5.0.3-pyhd3eb1b0_0
importlib-metadata pkgs/main/noarch::importlib-metadata-~ --> pkgs/main/win-64::importlib-metadata-3.7.3-py38haa95532_1
importlib_metadata 2.0.0-1 --> 3.7.3-hd3eb1b0_1
ipython 7.21.0-py38hd4e2768_0 --> 7.22.0-py38hd4e2768_0
jupyter_client 6.1.7-py_0 --> 6.1.12-pyhd3eb1b0_0
nbformat 5.1.2-pyhd3eb1b0_1 --> 5.1.3-pyhd3eb1b0_0
notebook 6.2.0-py38haa95532_0 --> 6.3.0-py38haa95532_0
pandoc 2.11-h9490d1a_0 --> 2.12-haa95532_0
parso 0.8.1-pyhd3eb1b0_0 --> 0.8.2-pyhd3eb1b0_0
pillow 8.1.2-py38h4fa10fc_0 --> 8.2.0-py38h4fa10fc_0
prometheus_client 0.9.0-pyhd3eb1b0_0 --> 0.10.0-pyhd3eb1b0_0
prompt-toolkit 3.0.8-py_0 --> 3.0.17-pyh06a4308_0
sqlite 3.33.0-h2a8f88b_0 --> 3.35.3-h2bbff1b_0
terminado 0.9.2-py38haa95532_0 --> 0.9.4-py38haa95532_0
zipp 3.4.0-pyhd3eb1b0_0 --> 3.4.1-pyhd3eb1b0_0
zstd 1.4.5-h04227a9_0 --> 1.4.9-h19a0ad4_0
The following packages will be DOWNGRADED:
libtiff 4.2.0-he0120a3_0 --> 4.1.0-h56a325e_1
Proceed ([y]/n)?
Why does conda want to update or downgrade all these other packages when the opposite wasn't done when I installed xlrd? Is there a way that I can safely remove the just xlrd. (I hear using --force is risky.)

Asymmetry
Conda re-solves when removing. When installing, Conda first attempts a frozen solve, which amounts to keeping all installed packages fixed and just searching for a version of the requested package(s) that are compatible. In this specific case, xlrd (v2.1.0) is a noarch with only a python>=3.6 constraint. So this installs in this frozen solve pass.
The constraint xlrd will also be added to the explicit specifications.1
When removing, Conda will first remove the constraint, and then re-solves the environment with the new set of explicit specifications. It is in this solve that Conda identifies that newer versions of packages and then proposes updating then.
So, the asymmetry is that the frozen solve explicitly avoids checking for any new packages, but the removal will trigger such a check. There is not currently a way to avoid this without bypassing dependency checking.
Mamba
Actually, mamba, a compiled (fast!) drop-in replacement for conda, will remove only the specified package if it doesn't have anything depending on it. That is its default behavior in my testing.
Addendum: Still Some Unexplained Behavior
I replicated your experience by first creating an environment with two specs:
name: foo
channels:
- conda-forge
dependencies:
- python=3.8.0
- pip=20
To simulate this being an old environment, I went into the envs/foo/conda-meta/history and changed2 the line
# update specs: ['pip=20', 'python=3.8.0']
to
# update specs: ['python=3.8']
Subsequently running conda install xlrd does as expected. Then conda remove xlrd gives a somewhat odd result:
## Package Plan ##
environment location: /opt/conda/envs/foo
removed specs:
- xlrd
The following packages will be downloaded:
package | build
---------------------------|-----------------
pip-21.1.1 | pyhd8ed1ab_0 1.1 MB conda-forge
------------------------------------------------------------
Total: 1.1 MB
The following packages will be REMOVED:
xlrd-2.0.1-pyhd8ed1ab_3
The following packages will be UPDATED:
pip 20.3.4-pyhd8ed1ab_0 --> 21.1.1-pyhd8ed1ab_0
Proceed ([y]/n)?
This effectively replicates OP result, however, the additional oddity here is that the python package is not suggested to be updated, even though I had intentionally loosened its constraint from 3.8.0 to 3.8. It appears that only packages not in the explicit specifications are subject to updating during package removal.
[1] The explicit specifications are the internally maintained records that Conda keeps of every constraint a user has explicitly specified. One can view the current explicit specifications of an environment with conda env export --from-history. The raw internal records can be found at yourenv/conda-meta/history.
[2] Not a recommended practice!

How do I see the summary or description for a conda package?

conda packages (can) have a summary and description in their metadata. I'd like to read those somehow using conda, to help decide what packages to install. However, the most information I can find is from conda search -i, e.g.
$ conda search -i optionsfactory
Loading channels: done
optionsfactory 1.0.3 py_0
-------------------------
file name : optionsfactory-1.0.3-py_0.tar.bz2
name : optionsfactory
version : 1.0.3
build : py_0
build number: 0
size : 22 KB
license : BSD-3-Clause
subdir : noarch
url : https://conda.anaconda.org/conda-forge/noarch/optionsfactory-1.0.3-py_0.tar.bz2
md5 : f8db4dd5600ad38b5f6ecae5f6f7d2ad
timestamp : 2020-05-13 08:04:25 UTC
dependencies:
- python >=3.6
which isn't helpful for finding out what the package actually does.

Resolving conflict with urllib3 to install AWS elastic beanstalk CLI using anaconda on Macos?

I'm trying to install the cli for aws elastic beanstalk using conda install -c davidbgonzalez awsebcli but I keep running into this error:
/Users/deepak/.local/lib/python2.7/site-packages/requests/__init__.py:80: RequestsDependencyWarning: urllib3 (1.23) or chardet (3.0.4) doesn't match a supported version!
RequestsDependencyWarning)
Solving environment: failed
UnsatisfiableError: The following specifications were found to be in conflict:
- awsebcli
- urllib3
Use "conda info <package>" to see the dependencies for each package.
Now this error appeared for many libraries- not just urllib3; but for each of those I was able to resolve by using either conda uninstall or pip install --upgrade. However, for urllib3, if I uninstall, the conda command itself doesn't work, as it says requests package not found, and if I update urllib3- it makes no difference, the conflict remains and I cant move forward with my awsebcli installation.
Help?
PS: I use a MacOS with conda 4.5.9 installation with python 2.7.14.
I tried a pip install awsebcli- and it installed properly, but I'm not able to locate the executable and thus not sure how to include it into the '$PATH' variable. So, I'm guessing I need to use conda install as that is the main python I use everywhere.
UPDATE:
this is the result of conda info urllib3
/Users/deepak/.local/lib/python2.7/site-packages/requests/__init__.py:80: RequestsDependencyWarning: urllib3 (1.23) or chardet (3.0.4) doesn't match a supported version!
RequestsDependencyWarning)
urllib3 1.21.1 py27_0
---------------------
file name : urllib3-1.21.1-py27_0.tar.bz2
name : urllib3
version : 1.21.1
build string: py27_0
build number: 0
channel : https://repo.anaconda.com/pkgs/free/osx-64
size : 151 KB
arch : x86_64
constrains : ()
date : 2017-06-21
license : MIT
license_family: MIT
md5 : 57332c18a93a2d82131212d52a0bafbf
platform : darwin
subdir : osx-64
url : https://repo.anaconda.com/pkgs/free/osx-64/urllib3-1.21.1-py27_0.tar.bz2
dependencies:
certifi
cryptography >=1.3.4
idna >=2.0.0
ipaddress
pyopenssl >=0.14
pysocks >=1.5.6,<2.0,!=1.5.7
python 2.7*
urllib3 1.21.1 py36_0
---------------------
file name : urllib3-1.21.1-py36_0.tar.bz2
name : urllib3
version : 1.21.1
build string: py36_0
build number: 0
channel : https://repo.anaconda.com/pkgs/free/osx-64
size : 153 KB
arch : x86_64
constrains : ()
date : 2017-06-21
license : MIT
license_family: MIT
md5 : 676e7d5b7366f2636edde60a528dbb22
platform : darwin
subdir : osx-64
url : https://repo.anaconda.com/pkgs/free/osx-64/urllib3-1.21.1-py36_0.tar.bz2
dependencies:
certifi
cryptography >=1.3.4
idna >=2.0.0
pyopenssl >=0.14
pysocks >=1.5.6,<2.0,!=1.5.7
python 3.6*
urllib3 1.21.1 py35_0
---------------------
file name : urllib3-1.21.1-py35_0.tar.bz2
name : urllib3
version : 1.21.1
build string: py35_0
build number: 0
channel : https://repo.anaconda.com/pkgs/free/osx-64
size : 154 KB
arch : x86_64
constrains : ()
date : 2017-06-21
license : MIT
license_family: MIT
md5 : 1c5e2fdfed928117f86c0a89c0b97b19
platform : darwin
subdir : osx-64
url : https://repo.anaconda.com/pkgs/free/osx-64/urllib3-1.21.1-py35_0.tar.bz2
dependencies:
certifi
cryptography >=1.3.4
idna >=2.0.0
pyopenssl >=0.14
pysocks >=1.5.6,<2.0,!=1.5.7
python 3.5*
urllib3 1.23 py35_0
-------------------
file name : urllib3-1.23-py35_0.tar.bz2
name : urllib3
version : 1.23
build string: py35_0
build number: 0
channel : https://repo.anaconda.com/pkgs/main/osx-64
size : 152 KB
arch : None
constrains : ()
license : MIT
license_family: MIT
md5 : 7e349638ccb5faad1b2f4378657e969f
platform : None
subdir : osx-64
timestamp : 1529348179047
url : https://repo.anaconda.com/pkgs/main/osx-64/urllib3-1.23-py35_0.tar.bz2
dependencies:
certifi
cryptography >=1.3.4
idna >=2.0.0
pyopenssl >=0.14
pysocks >=1.5.6,<2.0,!=1.5.7
python >=3.5,<3.6.0a0
urllib3 1.23 py27_0
-------------------
file name : urllib3-1.23-py27_0.tar.bz2
name : urllib3
version : 1.23
build string: py27_0
build number: 0
channel : https://repo.anaconda.com/pkgs/main/osx-64
size : 150 KB
arch : None
constrains : ()
license : MIT
license_family: MIT
md5 : 10fa8961318553993367293d607cd870
platform : None
subdir : osx-64
timestamp : 1529348370587
url : https://repo.anaconda.com/pkgs/main/osx-64/urllib3-1.23-py27_0.tar.bz2
dependencies:
certifi
cryptography >=1.3.4
idna >=2.0.0
ipaddress
pyopenssl >=0.14
pysocks >=1.5.6,<2.0,!=1.5.7
python >=2.7,<2.8.0a0
urllib3 1.22 py35he002d57_0
---------------------------
file name : urllib3-1.22-py35he002d57_0.tar.bz2
name : urllib3
version : 1.22
build string: py35he002d57_0
build number: 0
channel : https://repo.anaconda.com/pkgs/main/osx-64
size : 156 KB
arch : None
constrains : ()
license : MIT
license_family: MIT
md5 : caf79d85b6ad4c487988886198b7ad36
platform : None
subdir : osx-64
timestamp : 1505923648539
url : https://repo.anaconda.com/pkgs/main/osx-64/urllib3-1.22-py35he002d57_0.tar.bz2
dependencies:
certifi
cryptography >=1.3.4
idna >=2.0.0
pyopenssl >=0.14
pysocks >=1.5.6,<2.0,!=1.5.7
python >=3.5,<3.6.0a0
urllib3 1.23 py36_0
-------------------
file name : urllib3-1.23-py36_0.tar.bz2
name : urllib3
version : 1.23
build string: py36_0
build number: 0
channel : https://repo.anaconda.com/pkgs/main/osx-64
size : 152 KB
arch : None
constrains : ()
license : MIT
license_family: MIT
md5 : f582f82965d2bbdd0ac3b5b034ee2af4
platform : None
subdir : osx-64
timestamp : 1529348338677
url : https://repo.anaconda.com/pkgs/main/osx-64/urllib3-1.23-py36_0.tar.bz2
dependencies:
certifi
cryptography >=1.3.4
idna >=2.0.0
pyopenssl >=0.14
pysocks >=1.5.6,<2.0,!=1.5.7
python >=3.6,<3.7.0a0
urllib3 1.23 py37_0
-------------------
file name : urllib3-1.23-py37_0.tar.bz2
name : urllib3
version : 1.23
build string: py37_0
build number: 0
channel : https://repo.anaconda.com/pkgs/main/osx-64
size : 152 KB
arch : None
constrains : ()
license : MIT
license_family: MIT
md5 : 3cf975556522788681a2c6caf7a955ae
platform : None
subdir : osx-64
timestamp : 1530723151837
url : https://repo.anaconda.com/pkgs/main/osx-64/urllib3-1.23-py37_0.tar.bz2
dependencies:
certifi
cryptography >=1.3.4
idna >=2.0.0
pyopenssl >=0.14
pysocks >=1.5.6,<2.0,!=1.5.7
python >=3.7,<3.8.0a0
urllib3 1.22 py27hc3787e9_0
---------------------------
file name : urllib3-1.22-py27hc3787e9_0.tar.bz2
name : urllib3
version : 1.22
build string: py27hc3787e9_0
build number: 0
channel : https://repo.anaconda.com/pkgs/main/osx-64
size : 153 KB
arch : None
constrains : ()
license : MIT
license_family: MIT
md5 : 5c91bc08e0a7c2cf3726fea8bc6c504e
platform : None
subdir : osx-64
timestamp : 1505923615525
url : https://repo.anaconda.com/pkgs/main/osx-64/urllib3-1.22-py27hc3787e9_0.tar.bz2
dependencies:
certifi
cryptography >=1.3.4
idna >=2.0.0
ipaddress
pyopenssl >=0.14
pysocks >=1.5.6,<2.0,!=1.5.7
python >=2.7,<2.8.0a0
urllib3 1.22 py36h68b9469_0
---------------------------
file name : urllib3-1.22-py36h68b9469_0.tar.bz2
name : urllib3
version : 1.22
build string: py36h68b9469_0
build number: 0
channel : https://repo.anaconda.com/pkgs/main/osx-64
size : 155 KB
arch : None
constrains : ()
license : MIT
license_family: MIT
md5 : 603417ae48ed5fa80d809dfb91c47f55
platform : None
subdir : osx-64
timestamp : 1505923681524
url : https://repo.anaconda.com/pkgs/main/osx-64/urllib3-1.22-py36h68b9469_0.tar.bz2
dependencies:
certifi
cryptography >=1.3.4
idna >=2.0.0
pyopenssl >=0.14
pysocks >=1.5.6,<2.0,!=1.5.7
python >=3.6,<3.7.0a0
I uninstalled cryptography and idna using pip uninstall, but the conflict doesn't go- i get the same error when I conda install -c davidbgonzalez awsebcli.
What's wrong here?

It might be that you already have a urllib3 in your conda lib directory. Have you tried uninstalling urlliub3 prior to attempting to install awsebcli?
At any rate, installation of the awsebcli using conda is not officially supported. Furthermore, conda install -c davidbgonzalez awsebcli installs a version of the awsebcli almost 2 years old.
I tried a pip install awsebcli- and it installed properly, but I'm not able to locate the executable and thus not sure how to include it ...
Did you install it as sudo? If so, it would make it non-readable to your user (as it is not in your path). This is a common pitfall. I recommend using virtualenv with pip for the sanest experience. Let me know if this works.