Skip to main content

Configuring conda-forge.yml

You can configure how conda-forge is set up and built via the conda-forge.yml file that is present in the root directory of a feedstock.

Rerendering the feedstock after you modify this file is usually required and always a good idea (see Rerendering feedstocks).

The next section describes in detail the top-level fields in conda-forge.yml.

conda-forge.yml schema​

info
This documentation is autogenerated from conda-smithy's JSON Schema.

This model describes in detail the top-level fields in conda-forge.yml. General configuration options are described below within the Fields specifications. Additional examples are provided as part of the object description. Values and options are subject to change, and will be flagged as Deprecated as appropriate.

appveyor​

AppVeyor CI settings. This is usually read-only and should not normally be manually modified. Tools like conda-smithy may modify this, as needed.

azure​

Azure Pipelines CI settings. This is usually read-only and should not normally be manually modified. Tools like conda-smithy may modify this, as needed. For example:

azure:
    # flag for forcing the building all supported providers
    force: False
    # toggle for storing the conda build_artifacts directory (including the
    # built packages) as an Azure pipeline artifact that can be downloaded
    store_build_artifacts: False
    # toggle for freeing up some extra space on the default Azure Pipelines
    # linux image before running the Docker container for building
    free_disk_space: False
    # limit the amount of CI jobs running concurrently at a given time
    # each OS will get its proportional share of the configured value
    max_parallel: 25

Below is an example configuration for setting up a self-hosted Azure agent for Linux:

azure:
    settings_linux:
        pool:
            name: your_local_pool_name
            demands:
                - some_key -equals some_value
        workspace:
            clean: all
        strategy:
            maxParallel: 1

Below is an example configuration for adding a swapfile on an Azure agent for Linux:

azure:
    settings_linux:
        swapfile_size: 10GiB

If you need more space on Windows, you can use C: at the cost of IO performance:

azure:
    settings_win:
        variables:
            CONDA_BLD_PATH: "C:\bld"
            MINIFORGE_HOME: "C:\Miniforge"

bot​

This dictates the behavior of the conda-forge auto-tick bot which issues automatic version updates/migrations for feedstocks. A valid example is:

bot:
    # can the bot automerge PRs it makes on this feedstock
    automerge: true
    # only automerge on successful version PRs, migrations are not automerged
    automerge: 'version'
    # only automerge on successful migration PRs, versions are not automerged
    automerge: 'migration'

    # only open PRs if resulting environment is solvable, useful for tightly coupled packages
    check_solvable: true

    # The bot.inspection key in the conda-forge.yml can have one of seven possible values and controls
    # the bots behaviour for automatic dependency updates:
    inspection: hint  # generate hints using source code (backwards compatible)
    inspection: hint-all  # generate hints using all methods
    inspection: hint-source  # generate hints using only source code
    inspection: hint-grayskull  # generate hints using only grayskull
    inspection: update-all  # update recipe using all methods
    inspection: update-source  # update recipe using only source code
    inspection: update-grayskull  # update recipe using only grayskull
    inspection: disabled # don't update recipe, don't generate hints

    # any branches listed in this section will get bot migration PRs in addition
    # to the default branch
    abi_migration_branches:
        - 'v1.10.x'

    version_updates:
        # use this for packages that are updated too frequently
        random_fraction_to_keep: 0.1  # keeps 10% of versions at random
        exclude:
            - '08.14'

The abi_migration_branches feature is useful to, for example, add a long-term support (LTS) branch for a package.

build_platform​

This is a mapping from the target platform to the build platform for the package to be built. For example, the following builds a osx-64 package on the linux-64 build platform using cross-compiling.

build_platform:
    osx_64: linux_64

Leaving this field empty implicitly requests to build a package natively. i.e.

build_platform:
    linux_64: linux_64
    linux_ppc64le: linux_ppc64le
    linux_aarch64: linux_aarch64
    osx_64: osx_64
    osx_arm64: osx_arm64
    win_64: win_64

build_with_mambabuild​

Deprecated

build_with_mambabuild is deprecated, use conda_build_tool instead.

channel_priority​

The channel priority level for the conda solver during feedstock builds. For extra information, see the Strict channel priority section on conda documentation.

choco​

This parameter allows for conda-smithy to run chocoloatey installs on Windows when additional system packages are needed. This is a list of strings that represent package names and any additional parameters. For example,

choco:
    # install a package
    - nvidia-display-driver

    # install a package with a specific version
    - cuda --version=11.0.3

This is currently only implemented for Azure Pipelines. The command that is run is choco install {entry} -fdv -y --debug. That is, choco install is executed with a standard set of additional flags that are useful on CI.

circle​

Circle CI settings. This is usually read-only and should not normally be manually modified. Tools like conda-smithy may modify this, as needed.

clone_depth​

The depth of the git clone.

compiler_stack​

Deprecated

Compiler stack environment variable. This is used to specify the compiler stack to use for builds. Deprecated.

compiler_stack: comp7

conda_build​

Settings in this block are used to control how conda build runs and produces artifacts. An example of the such configuration is:

conda_build:
    pkg_format: 2
    zstd_compression_level: 16
    error_overlinking: False

conda_build_tool​

Use this option to choose which tool is used to build your recipe.

conda_forge_output_validation​

This field must be set to True for feedstocks in the conda-forge GitHub organization. It enables the required feedstock artifact validation as described in Output Validation and Feedstock Tokens.

conda_install_tool​

Use this option to choose which tool is used to provision the tooling in your feedstock. Defaults to micromamba.

If conda or mamba are chosen, the latest Miniforge will be used to provision the base environment. If micromamba or pixi are chosen, Miniforge is not involved; the environment is created directly by micromamba or pixi.

conda_solver​

Choose which conda solver plugin to use for feedstock builds.

config_version​

The conda-smithy config version to be used for conda_build_config.yaml files in recipe and conda-forge-pinning. This should not be manually modified.

docker​

This is a mapping for Docker-specific configuration options. Some options are

docker:
    executable: docker
    command: "bash"

drone​

Drone CI settings. This is usually read-only and should not normally be manually modified. Tools like conda-smithy may modify this, as needed.

exclusive_config_file​

Exclusive conda-build config file to replace conda-forge-pinning. For advanced usage only.

github​

Mapping for GitHub-specific configuration options. The defaults are as follows:

github:
    user_or_org: conda-forge
    repo_name: "my_repo"
    branch_name: main
    tooling_branch_name: main

github_actions​

GitHub Actions CI settings. This is usually read-only and should not normally be manually modified. Tools like conda-smithy may modify this, as needed.

idle_timeout_minutes​

Configurable idle timeout. Used for packages that don't have chatty enough builds. Applicable only to circleci and travis.

idle_timeout_minutes: 60

linter​

Settings in this block are used to control how conda smithy lints An example of the such configuration is:

linter:
    skip:
        - lint_noarch_selectors

matrix​

Deprecated

Build matrices were used to specify a set of build configurations to run for each package pinned dependency. This has been deprecated in favor of the provider field. More information can be found in the Build Matrices section of the conda-forge docs.

max_py_ver​

Deprecated

Maximum Python version. This is used to specify the maximum Python version to use for builds. Deprecated.

max_py_ver: 37

max_r_ver​

Deprecated

Maximum R version. This is used to specify the maximum R version to use for builds. Deprecated.

max_r_ver: 34

min_py_ver​

Deprecated

Minimum Python version. This is used to specify the minimum Python version to use for builds. Deprecated.

min_py_ver: 27

min_r_ver​

Deprecated

Minimum R version. This is used to specify the minimum R version to use for builds. Deprecated.

min_r_ver: 34

noarch_platforms​

Platforms on which to build noarch packages. The preferred default is a single build on linux_64.

noarch_platforms: linux_64

To build on multiple platforms, e.g. for simple packages with platform-specific dependencies, provide a list.

noarch_platforms:
  - linux_64
  - win_64

os_version​

This key is used to set the OS versions for linux_* platforms. Valid entries map a linux platform and arch to either cos7, alma8, alma9 or ubi8.

Currently alma9 is the default, which should work out-of-the-box for the vast majority of uses.

Note that the image version does not imply a matching glibc requirement (which can be set using c_stdlib_version in recipe/conda_build_config.yaml).

If you need to opt into older images, here's an example how to do it:

os_version:
    linux_64: cos7
    linux_aarch64: cos7
    linux_ppc64le: cos7

package​

Default location for a package feedstock directory basename.

private_upload​

Whether to upload to a private channel.

private_upload: False

provider​

The provider field is a mapping from build platform (not target platform) to CI service. It determines which service handles each build platform. If a desired build platform is not available with a selected provider (either natively or with emulation), the build will be disabled. Use the build_platform field to manually specify cross-compilation when no providers offer a desired build platform.

The following are available as supported build platforms:

  • linux_64
  • osx_64
  • win_64
  • linux_aarch64
  • linux_ppc64le
  • linux_s390x
  • linux_armv7l

The following CI services are available:

  • azure
  • circle
  • travis
  • appveyor
  • None or False to disable a build platform.
  • default to choose an appropriate CI (only if available)
  • native to choose an appropriate CI for native compiling (only if available)
  • emulated to choose an appropriate CI for compiling inside an emulation of the target platform (only if available)

For example, switching linux_64 & osx_64 to build on Travis CI, with win_64 on Appveyor:

provider:
    linux_64: travis
    osx_64: travis
    win_64: appveyor

Currently, x86_64 platforms are enabled, but other build platforms are disabled by default. i.e. an empty provider entry is equivalent to the following:

provider:
    linux_64: azure
    osx_64: azure
    win_64: azure
    linux_ppc64le: None
    linux_aarch64: None

To enable linux_ppc64le and linux_aarch64 add the following:

provider:
    linux_ppc64le: default
    linux_aarch64: default

recipe_dir​

The relative path to the recipe directory. The default is:

recipe_dir: recipe

remote_ci_setup​

This option can be used to override the default conda-forge-ci-setup package. Can be given with ${url or channel_alias}::package_name, defaults to conda-forge channel_alias if no prefix is given.

remote_ci_setup: ["conda-forge-ci-setup=4", "conda-build>=24.1"]

secrets​

List of secrets to be used in GitHub Actions. The default is an empty list and will not be used.

shellcheck​

Shell scripts used for builds or activation scripts can be linted with shellcheck. This option can be used to enable shellcheck and configure its behavior. This is not enabled by default, but can be enabled like so:

shellcheck:
    enabled: True

skip_render​

This option specifies a list of files which conda smithy will skip rendering. This is useful for files that are not templates, but are still in the recipe directory. The default value is an empty list [], which will consider that all files can be rendered. For example, if you want to skip rendering the .gitignore and LICENSE.txt files, you can add the following:

skip_render:
    - .gitignore
    - LICENSE.txt

templates​

This is mostly an internal field for specifying where template files reside. You shouldn't need to modify it.

test​

This is used to configure on which platforms a recipe is tested.

test: native_and_emulated

Will do testing only if the platform is native or if there is an emulator.

test: native

Will do testing only if the platform is native.

test_on_native_only​

Deprecated

This was used for disabling testing for cross-compiling.

warning
This has been deprecated in favor of the top-level `test` field. It is now mapped to `test: native_and_emulated`.

travis​

Travis CI settings. This is usually read-only and should not normally be manually modified. Tools like conda-smithy may modify this, as needed.

upload_on_branch​

This parameter restricts uploading access on work from certain branches of the same repo. Only the branch listed in upload_on_branch will trigger uploading of packages to the target channel. The default is to skip this check if the key upload_on_branch is not in conda-forge.yml. To restrict uploads to the main branch:

upload_on_branch: main

woodpecker​

Woodpecker CI settings. This is usually read-only and should not normally be manually modified. Tools like conda-smithy may modify this, as needed.