How do I resolve conflicts in an exported conda environment from macOS when installing on linux?

user_216229 0
Viewed 686

I have an environment.yaml, that I use to re-create conda environments as follows:

conda env create -p /home/chris/moneybox/env --file /home/chris/moneybox/environment.lock.yaml --force

On macOS, this works fine, on linux it fails after 30+ minutes with conflicts, but the output is, to me at least, impenetrable and I'm not able to figure out what I need to change.

I've put the output up as a gist. I can't make any sense of it, and while I've submitted a conda issue to try and get that improved, would anyone be able to tell me what's actually conflicting here and what changes I need to make to environment.lock.yaml to fix them?

conda python
1 Answers

Package requirements on macOS and linux are not always the same. And even when the requirements match perfectly, the set of available versions is not always identical. (Maybe conda-forge contains foobar-1.2.3 for linux, but foobar-1.2.4 for macOS.)

For those reasons, it is usually not possible to export a large environment's package list from macOS and expect it to work on linux, or vice-versa (in my experience, at least). Once an environment gets large enough, the probability becomes high that at least one package's requirements cannot be satisfied.

Therefore, you'll need to maintain two different environment.lock.yaml files, for macOS and for linux. Since you're starting with a file that works on macOS, one easy thing to try is to simply drop the patch versions from all of the requirements and see if conda can work with that.

So, I tried that on your file. It worked fairly quickly. (I will add the new lock file as a comment on your gist.) Admittedly, this is not ideal -- nearly half of the packages ended up with a slightly different version. You'll need to test the environment to make sure it still suits your needs.

If you really want the two environments to match as closely as possible, you could try iterating over the differences and reverting them one at a time until you encounter a failure. But that seems like more trouble than it's worth. Maybe a better strategy is to just look over the differences and see if any of them stand out to you. You know your use-case; maybe there are one or two packages you need to be really picky about, so hand-pick those versions and leave the rest alone.

user_1620940
Related