11

I've been trying to use this yml file to create an environment (I created the yml):

name: testenv
channels:
- esri
- scitools
- obspy
- conda-forge
- defaults
dependencies:
- appnope=0.1.0=py36_0
- libgfortran=3.0.0=0
- pip=9.0.1=py36_0
- python=3.6.2=0
- wheel=0.30.0=py_1
- pip:
  - ipython-genutils==0.2.0
  - jupyter-client==5.1.0
  - jupyter-console==5.1.0
  - jupyter-core==4.3.0
  - prompt-toolkit==1.0.15

however it always fails with the following error message:

Using Anaconda API: https://api.anaconda.org
Solving environment: failed

ResolvePackageNotFound:
  - wheel==0.30.0=py_1
  - appnope==0.1.0=py36_0

Is it searching the wrong channels for it? I can find these packages if I simply install them in the base conda install. Thanks for your help.

mnky9800n
  • 1,113
  • 2
  • 15
  • 33

4 Answers4

17

The problem is that the Anaconda isn't lying to me. Those packages don't exist in the linux channels however they do exist in the OSX channels. So it is a platform specific problem.

mnky9800n
  • 1,113
  • 2
  • 15
  • 33
  • Does the output from with the build info omitted work any better? The build can be found in format package=version=build_info, and generated via `conda env export --no-builds ` – Steven Kalt Jun 05 '18 at 21:54
  • 1
    I tried that and it didn't make a difference. I do remember fixing this by finding the builds that worked on linux. unfortunately I no longer have the mac anymore so I can't test it anymore. – mnky9800n Jun 07 '18 at 13:32
11

Had this same issue. Solved it by removing both the build versions AND package version (except for necessary package versions such as python=3.6.2 and any others.) The end yml file would look like this in order to be fully cross-platform:

name: testenv
channels:
- esri
- scitools
- obspy
- conda-forge
- defaults
dependencies:
- appnope
- libgfortran
- pip
- python=3.6.2
- wheel
- pip:
  - ipython-genutils
  - jupyter-client==5.1.0
  - jupyter-console
  - jupyter-core
  - prompt-toolkit
msamon
  • 315
  • 2
  • 7
4

To expand on the answer of @msamon. I had the same error and their answer solved 90% of the problem. There did however remain a number of packages that could still not be resolved. This is because some Windows installations/packages will have Windows-specific libraries that will of course never be available on Linux.

The solution is to remove the versioning values, run the Conda environment install again, and then completely delete from the .yml any remaining packages flagged as not present. Letting Conda handle any resulting missing dependencies and/or refactoring your code to use different libraries that do have distributions on the Linux channels.

I verified this approach on a transfer of environment using a .yml from a Windows 10 machine to a Linux remote machine with a Python3.6 install, via Conda4.9.2.

Tom Dowling
  • 61
  • 4
2

Sometimes found that pip does a better job than anaconda in package versioning. So after "activating" that anaconda environment, I do

while read req; do conda install --yes $req || pip install $req; done < ./requirements.txt

this way first I use anaconda, if that fails I try pip. Please note that i suggest "activating" that anaconda environment and then running the above command else it would pollute the global pip pool.

Srikar Appalaraju
  • 71,928
  • 54
  • 216
  • 264