ResolvePackageNotFound: Create env using conda and yml file on MacOS

Question

I want to create a virtual environment using conda and yml file.

Command:

conda env create -n ex3 -f env.yml

Type ENTER it gives fo

Answer 1

tl;dr conda env export --from-history -n name_of_your_env -f environment.yml

---

conda env export command pins your dependencies to the exact version along with OS specific details.

Looks like this for Pandas on macOS for example, - pandas=1.0.5=py38h959d312_0. conda env create cannot use this to create the same environment on other OS, like Linux inside Docker for instance.

So export the packages without pinning, and the ones you specifically installed after creating the conda environment, from history, using conda env export --from-history.

https://repo2docker.readthedocs.io/en/latest/howto/export_environment.html

Answer 2

I had same problem and found your question googling for it.

ResolvePackageNotFound error describes all packages not installed yet, but required.

To solve the problem, move them under pip section:

name: ex3
channels:
- menpo
- defaults
dependencies:
  - cairo=1.14.8=0
  - ***
  - another dependencies, except not found ones
  - pip:
    - gst-plugins-base==1.8.0                
    - bleach==1.5.0
    - enum34==1.1.6
    - html5lib==0.9999999
    - markdown==2.6.11
    - protobuf==3.5.1
    - tensorflow==1.4.1
    - tensorflow-tensorboard==0.4.0
    - werkzeug==0.14.1
    *** added ***
    - gst-plugins-base==1.8.0
    - dbus==1.10.20
    - opencv3==3.2.0
    - qt==5.6.2
    - libxcb==1.12
    - libgcc==5.2.0
    - gstreamer==1.8.0

Answer 3

There can be another reason for the 'ResolvePackageNotFound' error -- the version of the packages you require might be in an old version of the repository that is not searched by default.

The different paths to locations in the Anaconda repositories can be found at:
https://repo.continuum.io/pkgs/

My yml file [NW_BI.yml] is as follows:

name: NW_BI
channels:
- 'https://repo.continuum.io/pkgs/free' # Remove this line and it fails!!!
- conda-forge
- defaults
dependencies:
- python=2.7.10
- pandas=0.16.2
- pyodbc=3.0.10

Create using:

conda env create -f 'path to file'\NW_BI.yml

I wanted to recreate an old environment!!!!

Note using:
Anaconda3 2019.10
Windows10

Answer 4

I got the same issue and found a GitHub issue related to this. In the comments, @kalefranz posted an ideal solution by using the --no-builds flag with conda env export.

conda env export --no-builds > environment.yml

However, even remove build numbers, some packages may still have different version number at different OS. The best way I think is to create different env yml file for different OS.

Hope this helps.

Answer 5

If you are looking at this and feel too much chore to change Conda version packge=ver=py.* to pip style package==ver, I wrote this small script that delete the =py.* part from Conda style.

Note below code work on the presume that you already changed package=ver to package==ver.

#!/bin/bash

COUNT=0
find_pip=0

while IFS= read -r line; do
    COUNT=$(( $COUNT + 1 ))
#    echo "$COUNT"
#    echo "read it"
    if echo ${line} | grep -q -- "- pip:" ; then
#        echo "find it"
        find_pip=1
        indent=`awk -F- '{print length($1)}' <<< "$line"`
        pip_indent=$(( $indent + 2 ))
#        echo $indent
#    echo $pip_indent
    fi

    line_indent=`awk -F- '{print length($1)}' <<< "$line"`

    if [[ ${find_pip} ]] && [[ ${pip_indent} -eq ${line_indent} ]]; then
#        echo "$line"
        new_line=`echo ${line} | cut -d'=' -f-3`
        new_line="    $new_line"
#        echo "${new_line}"
        sed -e "${COUNT}s/.*/${new_line}/" -i '' $1
    fi
done < "$1"

Answer 6

I had a similar issue and was able to work around it. My issue wasn't related to pip but rather because the export platform wasn't the same as the import platform (Ref: nehaljwani's November 2018 answer on https://github.com/conda/conda/issues/7311).

@Shixiang Wang's answer point towards a part of the solution. The no-build argument allows for more flexibility but there are some components which are specific to the platform or OS.

Using the no-build export, I was able to identify (from the error message at import time) which libraries were problematic and simply removed them from the YML file. This may not be flawless, but saves a lot of time compared to starting from scratch.

NOTE: I got a Pip subprocess error which interrupted the installation at a given library, which could be simply overcome via a conda install <library>. From there I could relaunch the import from the YML file.