conda install conda raises UnsatisfiableError

[bsipocz]

While I was looking into whether our CI setup was compatible with the latest conda release, I run into a rather weird problem that on python 3.6 conda install conda with the version pinned to 4.3.23 in the pinned file raised:

UnsatisfiableError: The following specifications were found to be in conflict

The weirdest thing was that the same travis matrix contained jobs that finished earlier and successfully installed this version. I couldn't spot any difference in the versions of other packages in that env:

passing build:
https://travis-ci.org/bsipocz/photutils/jobs/260783392
failing build:
https://travis-ci.org/bsipocz/photutils/jobs/260783387

Here is our setup:
https://github.com/astropy/ci-helpers/blob/master/travis/setup_dependencies_common.sh#L49

[kalefranz]

Were you able to figure anything out here? I don't really understand the cause of the problem either from your description.

[bsipocz]

No, I can't remember that I found any logical explanation for this. Pinning the version to 4.3.21 was a good enough workaround, and now that we're about to update to either use 4.3.34 or 4.4.10, this hasn't come up again.
So I'm closing, but please reopen and investigate if anyone else runs into this again.

[kalefranz]

Thanks @bsipocz. We have 4.4.11 in the conda-canary channel right now, and 4.5.0 coming out probably next week. 4.5.0 is as substantial of feature release as 4.3 and 4.4 were. The main reason we're making the minor version bump is that we need to move the defaults repositories from repo.continuum.io to repo.anaconda.com. So for most users 4.5.0 should effectively be 4.4.12.

[kalefranz]

Actually, the biggest difference if you're still pinned to 4.3.21... In 4.3.27, we added https://repo.continuum.io/pkgs/main to the default value of defaults. That separate channel is how we isolated all of the work that went into the Anaconda 5.0 compiler stack (https://www.anaconda.com/blog/developer-blog/announcing-the-release-of-anaconda-distribution-5-0). It's a big win in terms of performance, security, and interoperability with conda-forge. But it also did cause transition problems for some users.

[bsipocz]

@kalefranz - My previous comment was a bit hasty, we are actually already on 4.3.27 (we were on 4.3.21 after this issue was opened, but then upgraded at some point). And I'm now about to upgrade the pin to 4.3.34 and also am testing how many issues we still have with 4.4.x.
Btw is that branch considered stable yet?

[kalefranz]

I believe it's pretty stable, yes. The only outstanding bug that might prevent me from saying "just as stable, or more stable" than 4.3.x is #6904. Hopefully I get that one resolved soon. There's a WIP PR for it right now.

[bsipocz]

Thanks. That issue shouldn't make any difference for CI testing, so I'll go ahead and try to make it work for ci-helpers.

[kalefranz]

Your team always seems to find crazy stuff, so let me know how it goes :)

The 4.4.11 release is in the conda-canary channel right now. It’ll be moved to defaults on Monday or sooner.

[mingwandroid]

@kalefranz, this might be a bug in conda 4.4, at least using conda 4.3 is the current workaround. I'm having to rebuild all of R 3.4.3 and MRO because of this problem.

conda/conda-build#2707

[kalefranz]

@mingwandroid this particular issue is almost certainly unrelated to conda 4.4. First reported 7 months ago with conda version pinned to 4.3.23.

[mingwandroid]

@kalefranz I was referring specifically to:

The only outstanding bug that might prevent me from saying "just as stable, or more stable" than 4.3.x is #6904.

[github-actions]

Hi there, thank you for your contribution to Conda!

This issue has been automatically locked since it has not had recent activity after it was closed.

Please open a new issue if needed.