channel_priority non-strict as warning

[mfansler]

Problem

Setting channel_priority: strict makes it impossible to provide precise specification of packages in lower priority channels.

Example

In the scUTRquant pipeline, we rely on a custom build of kallisto which includes features that are not merged into the main repository. We have an environment definition:

name: kallisto-bustools
channels:
  - conda-forge
  - bioconda
  - defaults
  - merv
dependencies:
  - merv::kallisto=0.46.2sq
  - bustools=0.40.0

It is clear that we specify that kallisto should come from the merv channel, even though that is not the highest priority channel. And only that channel provides that specific build. However, with the setting channel_priority: strict, any packages available first in a higher priority channel, such as bioconda, will mask their availability in lower priority channels. Hence, the solver cannot even see that the merv channel has the kallisto package. This leads to failure in solving.

Previously, users could set channel_priority: flexible, but now Snakemake has made this impossible due to raising an error with non-strict settings.

Proposed solution

Snakemake should change this to a warning, or provide an option so that users can choose whether it should raise a warning or an error.

Possible workarounds

We could rework the above environment definition to elevate the priority of the merv channel to above bioconda. This is undesirable because the channel also provides alternative builds of packages in bioconda that we may not want to mask.

Another alternative is to tell users that we only support Snakemake up to the release before this functionality was introduced. Obviously, we would prefer to constrain users' Snakemake versions as little as possible.

Additional discussion

I believe the choice to classify this Conda setting as an error is overly stringent. While I agree that Snakemake should be concerned with the reproducibility of solves, I would argue that raising this as a concern to the user in the form of a warning would be more appropriate. Configurations that make Snakemake unable to function should be errors, but configurations that Snakemake identifies as improvable should be warnings.

[johanneskoester]

Wow, I was indeed expecting that setting the channel name before the package will always work. Sorry for the hassle. I have changed the behavior to a warning as you suggest.