Gallery of toy recipes that implement "known conda-build patterns"

[jaimergp]

Where should the content be added?

This could be worth its own section

What should be added?

The idea is to have a set of recipes that implement known patterns that might be not obvious. One can always use the new search Github feature to look for similar examples, but they are often too complex (several patterns at once) to infer the known bits quickly.

Having single-pattern recipes (even if they do not really build real packages) could be a useful resource for users learning how to create recipes for conda-forge.

Additional information

Inspired by conversation in this Matrix thread.

[gschramm]

A few things that come to my mind are:

• use of "selectors" (e.g. cuda_comiler_version == )
• how to use run_exports
• runtime requirement on __cuda
• conventions for build strings
• difference between build and host requirement (especially when cross compiling)

[carterbox]

Related: https://github.com/conda-forge/staged-recipes/pull/19000#issuecomment-1235979325

I think we should lean towards a gallery of live recipes as much as possible instead of toy examples because there is less maintenance work and they would be kept up to date with current migrations and practices. It might be difficult to find live examples of specific patterns in isolation, but I'm sure they exist... somewhere in the catalogue 😉.

[carterbox]

I've reviewed a lot of simple CXX package recipes for @traversaro. Maybe he could link one simple compiled and one simple header-only example here to start our list.

https://github.com/conda-forge/tomopy-feedstock is an example of a feedstock which ships "a python/c package using ctypes" to which I would be willing to add explanatory markup.

[traversaro]

I've reviewed a lot of simple CXX package recipes for @traversaro. Maybe he could link one simple compiled and one simple header-only example here to start our list.

Sure (and thanks for all the reviews)!

• Example of simple compiled C++ library: https://github.com/conda-forge/libunicycle-footstep-planner-feedstock (PR to staged-recipes: https://github.com/conda-forge/staged-recipes/pull/20752)
• Example of simple header-only C++ library: https://github.com/conda-forge/vulkan-headers-feedstock (PR to staged-recipes: https://github.com/conda-forge/staged-recipes/pull/19868)

[dhirschfeld]

• A meta-package, only including other packages
• A go recipe with an example of including licenses via go-licenses

[hmaarrfk]

• A recipe using meson + cross compilation https://github.com/conda-forge/mesalib-feedstock/issues/46

[ocefpaf]

• It would be nice to add some of the "semi-arch" ones that use the OS virtual packages.

[jaimergp]

• It would be nice to add some of the "semi-arch" ones that use the OS virtual packages.

• We have https://github.com/conda-forge/conda-forge.github.io/pull/1839, which in a way depends on https://github.com/conda/conda-build/pull/4606

[bollwyvl]

Violently agreeing with https://github.com/conda-forge/conda-forge.github.io/issues/1908#issuecomment-1452425042: a curated "showcase" would likely be more useful over time, as it would not go out-of-date.

I imagine this as a single-file-PR docs build with a relatively flat folder structure.

pick your tool poison, please avoid nodejs. I'll assume sphinx with myst-parser.

conda-forge-showcase/
  README.md
  CONTRIBUTING.md
  .readthedocs.yaml
  environment.yml
  showcase.schema.yaml
  feestock.md.j2
  docs/
    conf.py
    index.md
    feedstocks/
      a-feedstock/
        showcase.yaml
      z-feedstock/
        showcase.yaml

Either in-line in the build, or as a preflight step:

• grab the tarball
• grab much of the "good stuff" directly from feedstock, e.g. "what packages used rust".
• run all that through a jinja template to generate the index.md for each of the files
  • syntax highlight the meta.yaml, conda_build_config.yaml, conda-forge.yml, build.sh, etc.

Gin up a showcase.schema.json (probably just written in YAML/TOML, no pydantic thanks) which provides a curated vocabulary of concepts which are not structurally derived.

For example:

notable_prs:
  123:
    description: adds noarch
    tags: [add-noarch]