Merge pull request #1624 from bollwyvl/add-noarch-platform

[wip] add noarch_platforms to knowledge base

Author: beckermr

src/maintainer/conda_forge_yml.rst

@@ -37,6 +37,7 @@ Top-level fields
 * :ref:`linux`
 * :ref:`linux_aarch64`
 * :ref:`linux_ppc64le`
+* :ref:`noarch_platforms`
 * :ref:`os_version`
 * :ref:`osx`
 * :ref:`provider`
@@ -152,7 +153,6 @@ Leaving this field empty implicitly requests to build a package natively. i.e.
       osx_arm64: osx_arm64
       win_64: win_64
 
-
 .. _build_with_mambabuild:
 
 build_with_mambabuild
@@ -270,7 +270,7 @@ defaults are as follows:
       repo_name: ""
       # branch name to execute on
       branch_name: master
-      # branch name to use for rerender+webservices github actions and 
+      # branch name to use for rerender+webservices github actions and
       # conda-forge-ci-setup-feedstock references
       tooling_branch_name: master
 
@@ -321,6 +321,26 @@ Currently only:
     linux_ppc64le:
       enabled: False
 
+.. _noarch_platforms:
+
+noarch_platforms
+----------------
+Platforms on which to build noarch packages. The preferred default is a
+single build on ``linux_64``.
+
+.. code-block:: yaml
+
+    noarch_platforms: linux_64
+
+To build on multiple platforms, e.g. for simple packages with platform-specific
+dependencies, provide a list.
+
+.. code-block:: yaml
+
+    noarch_platforms:
+      - linux_64
+      - win_64
+
 .. _os_version:
 
 os_version

src/maintainer/knowledge_base.rst

@@ -917,18 +917,23 @@ which restricts the corresponding conda-forge recipes from becoming ``noarch``.
 Therefore, some conda-forge recipes only create an actual package on specific Python versions and are otherwise an
 empty placeholder. This allows them to be safely installed under all Python versions and makes using ``skips`` unnecessary.
 
-Currently available packages:
+Similarly, some packages are `only` platform-specific dependency of a package, such as ``pywin32``, and have
+helper metapackages which can help recipes stay ``noarch``. The version of the `actual` package required
+can be controlled with ``run_constrained``, even for packages not available on all platforms.
 
-+-------------+-------------------+--------------+
-| Name        | Available on:     | Empty on:    |
-+=============+===================+==============+
-| dataclasses | python >=3.6,<3.7 | python >=3.7 |
-+-------------+-------------------+--------------+
-| enum34      | python =2.7       | python >=3.4 |
-+-------------+-------------------+--------------+
-| typing      |                   | python >=3   |
-+-------------+-------------------+--------------+
+Currently available packages:
 
++--------------------+-------------------+--------------+
+| Name               | Available on:     | Empty on:    |
++====================+===================+==============+
+| dataclasses        | python >=3.6,<3.7 | python >=3.7 |
++--------------------+-------------------+--------------+
+| enum34             | python =2.7       | python >=3.4 |
++--------------------+-------------------+--------------+
+| typing             |                   | python >=3   |
++--------------------+-------------------+--------------+
+| pywin32-on-windows | windows           | unix         |
++--------------------+-------------------+--------------+
 
 .. _knowledge:all-installs:
 
@@ -957,7 +962,7 @@ Noarch builds
 Noarch packages are packages that are not architecture specific and therefore only have to be built once.
 
 Declaring these packages as ``noarch`` in the ``build`` section of the meta.yaml, reduces shared CI resources.
-Therefore all packages that qualify to be noarch packages, should be declared as such.
+Therefore all packages that qualify to be noarch packages `should` be declared as such.
 
 
 .. _noarch:
@@ -977,7 +982,7 @@ In order to qualify as a noarch python package, all of the following criteria mu
     statement and add version constraint on python in ``host`` and ``run``
     section.
   - ``2to3`` is not used
-  - Scripts argument in setup.py is not used
+  - ``scripts`` argument in ``setup.py`` is not used
   - If ``console_scripts`` ``entry_points`` are defined in ``setup.py`` or ``setup.cfg``, they are also listed in
     the ``build`` section of ``meta.yaml``
   - No activate scripts
@@ -991,7 +996,7 @@ In order to qualify as a noarch python package, all of the following criteria mu
 
 .. note::
 
-  Only ``console_scripts`` entry points have to be listed in meta.yaml. Other entry points do not conflict
+  Only ``console_scripts`` entry points have to be listed in ``meta.yaml``. Other entry points do not conflict
   with ``noarch`` and therefore do not require extra treatment.
 
 .. note::
@@ -1000,9 +1005,16 @@ In order to qualify as a noarch python package, all of the following criteria mu
   ``noarch`` even if one of its dependencies is not available on a given platform. If this is the case, conda will
   display a helpful error message describing which dependency couldn't be found when it tries to install the package.
   If the dependency is later made available, your package will be installable on that platform without having to make
-  any changes to the feedstock. However, keep in mind that since ``noarch`` packages are built on Linux, all
-  dependencies must be available on Linux.
+  any changes to the feedstock.
+
+  By default, ``noarch`` packages are built on Linux, and all dependencies must be available on Linux.
+
+.. hint::
 
+  If a ``noarch`` package `cannot` be built on Linux, one or more ``noarch_platforms`` can be provided in
+  ``conda-forge.yml``. One example is `pywin32-on-windows <https://github.com/conda-forge/pywin32-on-windows-feedstock>`_,
+  which builds on Linux `and` Windows, with ``build_number`` offsets to create a pair packages, like
+  ``dataclasses``.
 
 If an existing python package qualifies to be converted to a noarch package, you can request the required changes
 by opening a new issue and including ``@conda-forge-admin, please add noarch: python``.