conda-forge

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

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

linter:
    skip:
        - lint_noarch_selectors

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

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.

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.

Choose which conda solver plugin to use for feedstock builds.

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

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

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

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.

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

docker:
    executable: docker
    command: "bash"

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

idle_timeout_minutes: 60

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

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

Currently alma9 is the default, though alma10 is available for opt-in where necessary. rocky10 may be added in the future.

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

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, making explicit that linux_64 & osx_64 build on azure (by default), and switching win_64 to Appveyor:

provider:
    linux_64: azure
    osx_64: azure
    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

Default location for a package feedstock directory basename.

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

recipe_dir: recipe

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"]

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

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

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

This was used for disabling testing for cross-compiling.

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

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.

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

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.

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

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

compiler_stack: comp7

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

min_py_ver: 27

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

max_py_ver: 37

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

min_r_ver: 34

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

max_r_ver: 34

Whether to upload to a private channel.

private_upload: False

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

The depth of the git clone.

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

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

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 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 and Windows:

azure:
    settings_linux:
        swapfile_size: 10GiB
    settings_win:
        variables:
            SET_PAGEFILE: 'True'

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"

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

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.

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

build_with_mambabuild is deprecated, use conda_build_tool instead.

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.