run_exports in MPI example

[njzjz]

Where should the content be changed?

https://conda-forge.org/docs/maintainer/knowledge_base.html#complete-example

What should be changed?

conda-forge.github.io/src/maintainer/knowledge_base.rst

Lines 803 to 806 in abb0e2e

	{% if mpi != 'nompi' %}
	run_exports:
	- {{ name }} * {{ mpi_prefix }}_*
	{% endif %}

I am wondering why there is no package exported for the nompi package.

I think it should be corrected to

    run_exports:
    {% if mpi != 'nompi' %}
      - {{ name }} * {{ mpi_prefix }}_*
    {% endif %}
    {% if mpi == 'nompi' %}
      - {{ name }}
    {% endif %}

Or, if the package should not be exported, run_constrained should be used instead of run_exports:

    {% if mpi != 'nompi' %}
    run_constrained:
      - {{ name }} * {{ mpi_prefix }}_*
    {% endif %}

Additional information

Originally submitted in conda-forge/plumed-feedstock#36, but I noticed it just copies the documentation.

Incorrect or outdated

• Incorrect
• Outdated

[leofang]

I think the text above the quoted example should help clarify the intent here?

conda-forge.github.io/src/maintainer/knowledge_base.rst

Lines 734 to 750 in abb0e2e

	If building with this library creates a runtime dependency on the variant, the build string pinning can be added to ``run_exports``.
	For example, if building against the nompi variant will work with any installed version, but building with a
	given mpi provider requires running with that mpi:
	::
	build:
	...
	{% if mpi != 'nompi' %}
	run_exports:
	- {{ name }} * {{ mpi_prefix }}_*
	{% endif %}
	Remove the ``if mpi...`` condition if all variants should create a strict runtime dependency based on the variant
	chosen at build time (i.e. if the nompi build cannot be run against the mpich build).

[njzjz]

I think the text above the quoted example should help clarify the intent here?

No, it doesn't clarify why the nompi variant doesn't have run_exports, even if it doesn't require the specific variant.

[leofang]

I think the text here can be improved. My interpretation of this sentence

building against the nompi variant will work with any installed version

is that an MPI-consuming package, referred to as X whose recipe is in discussion, can choose to not export itself, assuming it is quite stable across versions such that downstream packages of X do not care. At run time, any of the X's variants (nompi, mpich, openmpi, ...) can be used. This could make the downstreams' lives simpler because they just need to build against the nompi variant, avoiding bifurcation of CI pipelines.

However, obviously the stableness assumption is case by case, and arguably quite strong for most cases. In practice, we usually add run_exports unconditionally as you pointed out. If a downstream truly doesn't care about X's variants, then it can still add ignore_run_exports_from: X to ignore it.

I don't have good suggestions for better wording, as I imagine any new change would start overlapping with other sections and also make this already-long section even longer 😅