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.

InvalidArchiveError when installing openssl-1.1.1g through Anaconda 4.7.12 on Windows 10

I am trying to install requests module, and openssl keep causing the InvalidArchiveError.
I am using conda 4.7.12, python 3.8.2, on Windows 10 operating system. I had the same issue when installing other packages requiring openssl-1.1.1g. I have followed the advice from the error message to delete and re-download 'openssl-1.1.1g-he774522_0.tar.bz2', but I keep getting the same error.
Is this version of openssl broken or something? Any help will be greatly appreciated.
lykim#Louis MINGW64 ~/Desktop/master/Learning
$ conda install -c anaconda requests
Collecting package metadata (current_repodata.json): ...working... done
Solving environment: ...working... done
==> WARNING: A newer version of conda exists. <==
current version: 4.7.12
latest version: 4.8.3
Please update conda by running
$ conda update -n base conda
## Package Plan ##
environment location: C:\ProgramData\Anaconda3\envs\pytorch
added / updated specs:
- requests
The following packages will be downloaded:
package | build
---------------------------|-----------------
openssl-1.1.1g | he774522_0 5.8 MB anaconda
------------------------------------------------------------
Total: 5.8 MB
The following NEW packages will be INSTALLED:
brotlipy conda-forge/win-64::brotlipy-0.7.0-py38h1e8a9f7_1000
cffi anaconda/win-64::cffi-1.14.0-py38h7a1dbc1_0
chardet anaconda/win-64::chardet-3.0.4-py38_1003
cryptography anaconda/win-64::cryptography-2.9.2-py38h7a1dbc1_0
idna anaconda/noarch::idna-2.9-py_1
pycparser anaconda/noarch::pycparser-2.20-py_0
pyopenssl anaconda/win-64::pyopenssl-19.1.0-py38_0
pysocks anaconda/win-64::pysocks-1.7.1-py38_0
requests anaconda/win-64::requests-2.23.0-py38_0
urllib3 conda-forge/noarch::urllib3-1.25.9-py_0
win_inet_pton anaconda/win-64::win_inet_pton-1.1.0-py38_0
The following packages will be SUPERSEDED by a higher-priority channel:
certifi conda-forge::certifi-2020.4.5.1-py38h~ --> anaconda::certifi-2020.4.5.1-py38_0
openssl conda-forge --> anaconda
Proceed ([y]/n)? y
Downloading and Extracting Packages
openssl-1.1.1g | 5.8 MB | ########## | 100%
InvalidArchiveError('Error with archive C:\\ProgramData\\Anaconda3\\pkgs\\openssl-1.1.1g-he774522_0.tar.bz2. You probably need to delete and re-download or re-create this file. Message from libarchive was:\n\nCould not unlink')
(pytorch)

I encountered the same problem a couple of times. This time my problem was solved simply by closing down jupyter notebook, which was running and using openssl, so if your python is running somewhere, try to close it down. (In addition had already removed openssl-1.1.1g-he774522_0.tar.bz2 and a number of folders openssl-1.1.1g-he774522_0 containing also those .tar balls, so that might be necessary as well)

You may try to go to your packages directory
C:\ProgramData\Anaconda3\pkgs\
Then delete openssl-1.1.1g-he774522_0.tar.bz2 file, install libarchive and reinstall your package.
Another Solution
Simply you can install on your anaconda environment using pip instead of conda, anyway i recommend to update your conda too.

Encountered the same error, I think it was caused by an earlier failed installation which had left an incomplete openssl-1.1.1g-he774522_0 directory in users\username\Anaconda3\pkgs. Just delete it and then it completes just fine.

I had the same issue. There was some "openssl*" folders. Deleted them, and the "openssl*" .bz2 files as well, and tried to install again. Now works perfectly.
Eventually the folders can't be deleted because they're used by other programs. If it happens, go to Task Manager and close python.exe.

I was able to fix my error by elevating my command window. The delete method wasn't working.

Installing OpenCV with Conda

Installing packages to start running some code is perhaps the hardest part of my job.
Anways, I tried installing opencv for use in anaconda python 3.6 environment. And I get the error:
conda install -c conda-forge opencv
Fetching package metadata ...........
Solving package specifications: ..........
Package plan for installation in environment C:\Program Files\Anaconda3\envs\py36:
The following packages will be downloaded:
package | build
---------------------------|-----------------
libwebp-0.5.2 | vc14_7 1.1 MB conda-forge
opencv-3.2.0 | np112py36_204 92.0 MB conda-forge
------------------------------------------------------------
Total: 93.1 MB
The following NEW packages will be INSTALLED:
libwebp: 0.5.2-vc14_7 conda-forge [vc14]
opencv: 3.2.0-np112py36_204 conda-forge
Proceed ([y]/n)? y
Fetching packages ...
libwebp-0.5.2- 100% |###############################| Time: 0:00:05 213.41 kB/s
opencv-3.2.0-n 100% |###############################| Time: 0:00:48 1.97 MB/s
Extracting packages ...
[ COMPLETE ]|##################################################| 100%
Linking packages ...
PaddingError: Placeholder of length '34' too short in package conda-forge::opencv-3.2.0-np112py36_204.
The package must be rebuilt with conda-build > 2.0.
I am on a Windows System. I do not understand the error and searching isn't helping.
Any comments or suggestions to resolve the error are welcome.

For the record, OpenCV installs fine with pip.
Tested on Windows 10 with Miniconda and Python 3.6:
> pip search opencv
...
opencv-python
...
> pip install opencv-python
Tells me Requirement already satisfied.
To make sure it was correctly installed, run:
> python
>>> import cv2
>>>

Go to the root conda environment.
And do conda update conda.
Then just import cv2 and use it.

Managing packages: PyCharm vs conda vs pip

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)

Anaconda: Error while building from PyPi package ("Package XY missing in current linux-64 channels")

I am trying to build a conda package of the open energy modelling framework (oemof) PyPi package as described in the respective manual. The oemof package has the Pyomo package as a requirement which I had installed in advance using a suitable recipe.
My problem is that I now get an error during the build process:
Package missing in current linux-64 channels:
- pyomo >=4.2.0
wheras my installed Pyomo version seems to be above 4.2:
cord#crd-Laptop:~/.anaconda3/bin$ ./conda update pyomo
pyomo 4.2.10784 py35_10 cachemeorg
What's my mistake here and how can I build my package as described in the conda manual?
Thanks in advance!
Below you can see the steps I went through so far:
cord#crd-Laptop:~/.anaconda3/bin$ ./conda skeleton pypi oemof
Warning, the following versions were found for oemof
0.0.6
0.0.5
0.0.4
0.0.3
Using 0.0.6
Use --version to specify a different version.
Using url https://pypi.python.org/packages/3b/1f/5a82acf8cbcb3d0adb537346b2939cb6fa415e9c347f734af19c8a1b50d1/oemof-0.0.6.tar.gz (52 KB) for oemof.
Downloading oemof
Using cached download
Unpacking oemof...
done
working in /tmp/tmpd67mbpi2conda_skeleton_oemof-0.0.6.tar.gz
Using Anaconda Cloud api site https://api.anaconda.org
Fetching package metadata: ......
Solving package specifications: .........
The following NEW packages will be INSTALLED:
mkl: 11.3.1-0
numpy: 1.11.0-py35_0
openssl: 1.0.2g-0
pip: 8.1.1-py35_1
python: 3.5.1-0
pyyaml: 3.11-py35_1
readline: 6.2-2
setuptools: 20.7.0-py35_0
sqlite: 3.9.2-0
tk: 8.5.18-0
wheel: 0.29.0-py35_0
xz: 5.0.5-1
yaml: 0.1.6-0
zlib: 1.2.8-0
Linking packages ...
[ COMPLETE ]|###########################################################################################| 100%
Applying patch: '/tmp/tmpd67mbpi2conda_skeleton_oemof-0.0.6.tar.gz/pypi-distutils.patch'
patching file core.py
Hunk #1 succeeded at 167 with fuzz 2 (offset 1 line).
Using "UNKNOWN" for the license
Writing recipe for oemof
Done
cord#crd-Laptop:~/.anaconda3/bin$ ./conda build oemof
Removing old build environment
Removing old work directory
BUILD START: oemof-0.0.6-py35_0
Using Anaconda Cloud api site https://api.anaconda.org
Fetching package metadata: ......
Solving package specifications: .
Package missing in current linux-64 channels:
- pyomo >=4.2.0
Missing dependency pyomo, but found recipe directory, so building pyomo first
Ignoring non-recipe: pyomo
Removing old build environment
Removing old work directory
BUILD START: oemof-0.0.6-py35_0
Fetching package metadata: ......
Solving package specifications: .
Package missing in current linux-64 channels:
- pyomo >=4.2.0
cord#crd-Laptop:~/.anaconda3/bin$ ./conda update pyomo
Using Anaconda Cloud api site https://api.anaconda.org
Fetching package metadata: ....
# All requested packages already installed.
# packages in environment at /home/cord/.anaconda3:
#
pyomo 4.2.10784 py35_10 cachemeorg
cord#crd-Laptop:~/.anaconda3/bin$

For your build step please try conda build -c cachemeorg oemof.
I believe the problem here is that conda build creates a whole new conda environment when it is building and it will install all the package dependencies, including pyomo, in that environment. It installs them by looking for them in the channels and not via your currently installed packages in your root. In this example you have pyomo installed as a package but that didn't come from a channel in your channels list as you installed it yourself. Therefore it fails to find the pyomo package when searching your conda channels. But if we add a channel to the list that conda build is looking at (via the -c flag) which has pyomo then it should work. It looks like cachemeorg has this package and therefore the above command should work.