It would be nice if conda could handle 3 scenarios when solving packages via an option on the .condarc. The options would be:

0: no channel preference, solve for the newest versions (already possible with a config option)
1: "some" channel preference (the current status)
2: "strict" channel preference (not implemented)

Rationale for this request:

At the moment if we use 1 we may get a different solution for two virtually identical environments, for example one with cartopy only and another one with cartopy and matplotlib may yield different soluytions. The reason for that is b/c in the former matplotlib is implicit and conda won't prioritize it, on the second one conda will prioritize matplotlib along-side with cartopy. (@kalefranz please correct me if I am wrong.)

Also, under this scenario one may get a bad mix of packages from different channels that is hard to debug. With option 2 both envs above would have the same solution and an unsolvable env would result in an error rather than a broken mix packages from different channels.

The "strict" option would solve packages for the first priority channel and look for packages on the lower priority only if they are not present in the first priority.

It would make an env like this,

name: mapping
channels:
  - defaults
dependencies:
  - python=3.6
  - cartopy
  - conda-forge::folium
  - conda-forge::compliance-checker
  - conda-forge::gsw

simpler because we could just add conda-forge as the lower priority in the list of channels and drop the conda-forge:: syntax for the other packages. Note that when there are many packages exclusively on the lower priority channel this can be very convenient.

Another scenario would be to allow for third party channel to easily use defaults compilers and runtimes without the need to incorporate them (or vendorize, ping @scopatz 😉) into their channel. Ensuring they are always getting the latest and most stable compiler/runtime while still building their env with the third party channel.

Note that none of the options above would ensure a stable env! However, option 2 is arguably the only one easy to debug and we expect "unsolvable" envs to happen rather than a bad mix of channels.