Merge pull request #2537 from h-vetinari/pin_comp

remove remaining leftovers of old numpy pinning

Author: xhochy

docs/maintainer/adding_pkgs.md

@@ -1174,7 +1174,6 @@ Jinja expressions serve following purposes in the meta.yaml:
       - numpy
     run:
       - python
-      - {{ pin_compatible('numpy') }}
   ```
 
 For more information please refer to the [Templating with Jinja](https://docs.conda.io/projects/conda-build/en/stable/resources/define-metadata.html#templating-with-jinja) section in the conda-build docs.

docs/maintainer/pinning_deps.md

@@ -44,23 +44,38 @@ Should be replaced by
 requirements:
   host:
     - gmp
+  # most libraries will automatically add the corresponding runtime requirement using
+  # a so-called "run-export" from the gmp build pulled into the host environment.
+  # In that case you can leave out the following run-requirement:
   run:
     - gmp
 ```
 
-When there's a new ABI version of gmp (say 7.0), then conda-forge-pinning will be updated. A re-rendering of a package using gmp will change. Therefore to check that a recipe needs to be rebuilt for updated pinnings, you only need to check if the package needs a rerender.
+The run-export mechanism (see below) additionally ensures the correct version constraints
+(corresponding to the expected API/ABI stability of `gmp`) are added, so a recipe with an
+unpinned `gmp` dependency in the host environment will, in the end, work as follows:
 
-:::note
+```yaml
+requirements:
+  host:
+    - gmp {{ version_from_global_pinning }}.*
+  run:
+    - gmp >={{ version_from_global_pinning }},<{{ next_version_with_breaking_changes }}
+```
 
-`NumPy` is an exception to this (See [Building Against NumPy](knowledge_base.md#linking-numpy)).
+When there's a new ABI version of gmp (say 7.0), then conda-forge-pinning will be updated. A re-rendering of a package using gmp will change. Therefore to check that a recipe needs to be rebuilt for updated pinnings, you only need to check if the package needs a rerender.
 
 :::
 
 If a package is not pinned in [conda-forge-pinning](https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/master/recipe/conda_build_config.yaml), then the pinning needs to be done manually. If the package is a `C/C++` library with a `C/C++` API that is consumed and linked to by other libraries, then that package is a candidate to be added to `conda-forge-pinning`. Please open an issue in [conda-forge-pinning-feedstock](https://github.com/conda-forge/conda-forge-pinning-feedstock) for discussion.
 
 :::note
 
-If the constraints in `conda-forge-pinning` are not strict enough, you can override them by changing back to pinning the package with a version manually. You can make a pinning stricter by adding `{{ pin_compatible('gmp', max_pin='x.x.x') }}` to run requirements.
+If the constraints in `conda-forge-pinning` (resp. those coming from the package's run-exports)
+are not strict enough, you can override them by changing back to pinning the package with
+a version manually.
+You can make a pinning stricter by adding `{{ pin_compatible('gmp', max_pin='x.x.x') }}`
+to run requirements.
 
 :::