Adding host_exports (like run_exports except between build & host only)

[jakirkham]

run_exports has been immensely helpful. Just to summarize it run_exports:

• Allows packages with knowledge of what they need to express it for easy downstream consumption
  • Packages that are part of the build can add dependency to run
    • weak only happens when the dependency is added to host (not build)
    • strong happens when a dependency is added to build or host
  • Dependencies added can express ABI compatibility

However there are still some cases that are not covered. In particular there are cases where a dependency added to build needs to add itself to host, but there is no need to add it to run (in fact this would often be better to avoid). IOW run_exports/strong does not meet this need. Some examples include:

• Header-only dependencies of a package
  • Build/host dependency of header-only C++ packages conda-build#3796 (comment)
• Tighter alignment in build & host of compiler dependencies (like OpenMP)
  • Specifying llvm-openmp only in build leads to a run_exports against the latest llvm-openmp conda-forge/openmp-feedstock#126
• Compiler runtime libraries that are statically linked (like cudart)
  • Adding cuda-cudart conda-forge/staged-recipes#21723 (comment)
• Other compiler use cases
  • Build exports conda-build#3966

Solving these cases would involve a host_exports that allows adding other dependencies to host. Could imagine to use cases for a package providing host_exports

• host_exports/weak (default)
  • Add dependencies to host if providing package is added to host
  • Solves the header-only dependency case above for a library
• host_exports/strong (opt-in)
  • Add dependencies to host if providing package is in build or host
  • Handles the compiler dependency alignment problem (with OpenMP)
  • Handles statically linked compiler libraries (like cudart)
  • Of most use for compiler use cases

[jakirkham]

cc @xhochy (for awareness)

[jakirkham]

@jaimergp @wolfv would be interested to hear your perspectives on this idea? 🙂

[jaimergp]

I'm generally supportive of the idea provided that it's useful for a wide range of cases. A quick look made me see it as a "couple of edge cases". For example, it's not clear to me what "Add dependencies to host if providing package is added to host" means; if the package is already in host, why do we need to export anything? Is it to constrain it further? I guess we can use pin_compatible but we want to avoid that "annoyance" if the package in build already knows how tell host, right?

[jakirkham]

Thanks Jaime! 🙏

Am happy with limiting it to the case where a package is added to requirements/build

So that would mean there is no need for host_exports/weak and host_exports/strong could just be host_exports

Does that same more reasonable?

[jaimergp]

run_exports also started as a flat value with just the list of specs and then later decided to allow the map form with weak and strong, so I could see how we start with just host_exports: [specs]. Anyway, I'm not the most knowledgeable person here to dictate how this design should look like, but I do want to help you get the ball rolling. I think what you have already is good enough for a CEP PR and then we all can discuss the different options there!