How to force req/run versions equal to req/host without explicit pinning?

[IM-USAF]

I have a c++ conda package (https://github.com/conda-forge/tip-feedstock) which does not have strict build time version requirements on dependency libraries. Therefore, dependencies in req/host section are defined without any version logic. Runtime dependency libraries must have the same file name as those established during build time and I can't find an obvious way to communicate this in req/run. I can see two failures modes with the dependency declarations that I've read about in the documentation for req/run:

1. Some of those dependencies define build/run_exports which automatically insert into req/run and restrict the version range, which is a good thing. However, some dependencies may produce updated versions in which the revision or minor number is bumped in such a way that breaking changes "sneak" past the version logic implied by run_exports. The result is a solved environment with an executable that looks for, say *.so.1.11.2 while only *.so.1.11.3 exists.
2. Dependencies which don't define run_exports are declared explicitly in req/run and use pin_compatible("xxx", max_pin="x"). This declaration can result in a version upper bound which allows solved environments with incorrect libraries. I can further restrict versions via max_pin="x.x.x" but this seems to be a hack because it neglects the versioning semantic of a particular package. If I am incorrect here, please correct me.

So how do I say "Whatever req/host dependencies are used, require the exact same for req/run"?

[carterbox]

There is a keyword argument "exact" for the pinning expressions.

pin_compatible("xxx", exact=True)

However, exact pinning includes the build string which is unique to conda-forge and has nothing to do with upstream versioning. max_pin='x.x.x' should be sufficient because the ABI should not change between multiple conda-forge builds of the same version of a package.

https://docs.conda.io/projects/conda-build/en/latest/resources/variants.html#extra-jinja2-functions
https://github.com/conda/conda-build/blob/c752fc43b88928321eb7632a9840476b1b93abd0/conda_build/jinja_context.py#L206

[IM-USAF]

Thank you. Do you suggest using exact=True in the case of deps for which run_exports have been defined in way which may not be strict enough? I think that would create two dependency entries for library in question in repodata.json. During solving, does the logic resolve to the most limited case?

[carterbox]

The result is a solved environment with an executable that looks for, say *.so.1.11.2 while only *.so.1.11.3 exists.

A SO name change from so.1.11.2 to so.1.11.3 is not ABI breaking (according to conventional SO naming rules), so if you are linking to the full SO version instead of just so.1, then that's a problem specific to your situation/package. In this case, change your linking arguments or pin_compatible("foo", max_pin='x.x.x').

During solving, does the logic resolve to the most limited case?

The environment solver can find the union of multiple constraints for a package.

Do you suggest using exact=True in the case of deps for which run_exports have been defined in way which may not be strict enough?

No. exact=True is used for single recipes with multiple outputs because the outputs (including metadata) are tightly coupled.

In theory, package managers should be setting their run_exports according to the ABI compatability of the package they are shipping. i.e. The SO name MAJOR version should remain the same for all versions compatible with the run_export. If you think the run_exports of a package are not strict enough, please open an issue for that package's feedstock. If the package is on http://abi-laboratory.pro/, then it should be easy to verify at what API versions ABI breaks occur (not every upstream project follows conventional SO naming rules).

[IM-USAF]

Thanks. I have a much better understanding now.