Does "rerendering the feedstock" pertain to my own project's conda build?

Question

I'm confused by the conda-forge "feedstock" and when it's necessary to "rerender" it.

I find advice on what CDT packages to include in my project's recipe, if I'm linking against libGL (which I am), here. And the last thing it says is:

You will need to re-render the feedstock after making these changes.

That makes it sound like changing my own project's recipe requires me to "re-render the feedstock"; is that correct?

I've made several attempts at this, to no avail:

Traceback from `conda smithy rerender -c auto` command

$ conda smithy rerender -c auto
INFO:conda_smithy.configure_feedstock:Downloading conda-forge-pinning-2023.03.18.10.09.36
INFO:conda_smithy.configure_feedstock:Extracting conda-forge-pinning to /tmp/tmp_kk_rkwr
Traceback (most recent call last):
  File "/home/dbanas/miniconda3/bin/conda-smithy", line 10, in <module>
    sys.exit(main())
  File "/home/dbanas/miniconda3/lib/python3.10/site-packages/conda_smithy/cli.py", line 669, in main
    args.subcommand_func(args)
  File "/home/dbanas/miniconda3/lib/python3.10/site-packages/conda_smithy/cli.py", line 485, in __call__
    self._call(args, tmpdir)
  File "/home/dbanas/miniconda3/lib/python3.10/site-packages/conda_smithy/cli.py", line 490, in _call
    configure_feedstock.main(
  File "/home/dbanas/miniconda3/lib/python3.10/site-packages/conda_smithy/configure_feedstock.py", line 2272, in main
    config = _load_forge_config(forge_dir, exclusive_config_file, forge_yml)
  File "/home/dbanas/miniconda3/lib/python3.10/site-packages/conda_smithy/configure_feedstock.py", line 1832, in _load_forge_config
    raise RuntimeError(
RuntimeError: Could not find config file /home/dbanas/prj/PyBERT/conda-forge.yml. Either you are not rerendering inside the feedstock root (likely) or there's no `conda-forge.yml` in the feedstock root (unlikely). Add an empty `conda-forge.yml` file in feedstock root if it's the latter.

$ touch conda-forge.yml

$ conda smithy rerender -c auto
INFO:conda_smithy.configure_feedstock:Downloading conda-forge-pinning-2023.03.18.10.09.36
INFO:conda_smithy.configure_feedstock:Extracting conda-forge-pinning to /tmp/tmp3qlwn8vo
INFO:conda_smithy.configure_feedstock:__pycache__ rendering is skipped
INFO:conda_smithy.configure_feedstock:README rendering is skipped
Traceback (most recent call last):
  File "/home/dbanas/miniconda3/bin/conda-smithy", line 10, in <module>
    sys.exit(main())
  File "/home/dbanas/miniconda3/lib/python3.10/site-packages/conda_smithy/cli.py", line 669, in main
    args.subcommand_func(args)
  File "/home/dbanas/miniconda3/lib/python3.10/site-packages/conda_smithy/cli.py", line 485, in __call__
    self._call(args, tmpdir)
  File "/home/dbanas/miniconda3/lib/python3.10/site-packages/conda_smithy/cli.py", line 490, in _call
    configure_feedstock.main(
  File "/home/dbanas/miniconda3/lib/python3.10/site-packages/conda_smithy/configure_feedstock.py", line 2318, in main
    render_azure(env, config, forge_dir, return_metadata=True)
  File "/home/dbanas/miniconda3/lib/python3.10/site-packages/conda_smithy/configure_feedstock.py", line 1412, in render_azure
    return _render_ci_provider(
  File "/home/dbanas/miniconda3/lib/python3.10/site-packages/conda_smithy/configure_feedstock.py", line 636, in _render_ci_provider
    with open(
FileNotFoundError: [Errno 2] No such file or directory: '/home/dbanas/prj/PyBERT/recipe/meta.yaml'

$ conda smithy rerender -c auto conda.recipe/enable/
usage: conda smithy [-h] [--version]
                    {init,register-github,register-ci,azure-buildid,regenerate,rerender,recipe-lint,ci-skeleton,update-cb3,generate-feedstock-token,register-feedstock-token,update-anaconda-token,rotate-anaconda-token,update-binstar-token,rotate-binstar-token}
                    ...
conda smithy: error: unrecognized arguments: conda.recipe/enable/

Can anyone shed some light here?

score 0 · Accepted Answer · answered Mar 18 '23 at 15:45

Feedstock rerendering doesn't change a recipe per se (i.e., not anything under the recipe/ folder), but it can update the CI configuration, CI build scripts, the version pins on dynamically linked libraries, and the README for the feedstock. That is, it changes the context in which a recipe is built. Conda Forge recipes may require feedstock rerendering after the following changes:

system-level requirements, such as yum_requirements.txt: these need to be installed on the Docker image at the system level, typically in order for the test to run correctly. libGL is an example of this.
platform build variants: in order to build for a platform, Conda Smithy needs to generate the CI build configuration and build scripts. For example, adding support for osx-arm64 platform will require a rerender.
dynamically-linked libraries: many libraries have specific versions pinned in the conda-forge-pinning-feedstock. Rerendering will grab the latest pinned versions for any host-level requirements and define that as the version to be used when building the feedstock. There are options to have more control over this, but generally it is recommended to use the pinned version as this implicitly defines what packages are co-compatible because they use consistent library versions.
about metadata: the information in the about section gets rendered into the feedstock's README via Conda Smithy. For example, a license change, a change in description text, or updated URLs for the upstream project would all need to be updated in the README and thus require a rerender.

Generally, it is recommended to always rerender the feedstock when changes are made to a recipe because core developers may have updated to conda-smithy, the CI build scripts, or the conda-forge-pinning-feedstock, and this is how those changes propagate out to all packages.

Does "rerendering the feedstock" pertain to my own project's conda build?

1 Answers1