We mention in an admonition under https://pyodide.org/en/stable/development/new-packages.html#creating-the-meta-yaml-file that the recipe format was inspired by conda but isn't strictly compatible with it, and conda restricts additional fields. If we have to do this, we should supply our own schema even if it's a subset of that of conda's¹. Text editors like Visual Studio Code are currently listing our recipe format as "conda metadata build recipe" in the bottom right.

Tools like cibuildwheel also have their own schemas which are then hosted in an external place like https://json.schemastore.org/partial-cibuildwheel.json

And here's one for conda-forge: https://raw.githubusercontent.com/conda-forge/conda-smithy/main/conda_smithy/data/conda-forge.json

Fine with me, these fields are strictly informational so I am not that concerned. It's nice if the licenses are accurate though.

Fine with me, these fields are strictly informational so I am not that concerned. It's nice if the licenses are accurate though.

Yes, I expect that any problems with the format could increase, but only after we unvendor recipes and when they don't get to be in the main repository anymore. The licenses could be renamed to a license-expression: perhaps – and validated with the list that SPDX provides? https://spdx.org/licenses/. The recent PEP 639 (while provisional) is going to mark a shift for PyPI build backends, maybe conda-forge will adjust to this, too (and that means we should, too).