24 docs tagged with "how-to"

The following how-to guides are available in this category:

The following how-to guides are available in this category:

The following guides cover building conda-forge packages that depend on the CUDA Toolkit. They assume familiarity with writing recipes for compiled code (see Compilers and Runtimes) and with the user guide for running CUDA code.

The following guides cover topics specific to building packages for Windows on conda-forge.

Windows recipes rely on CMD/Batch scripts (.bat) by default.

In order to compile native code (C, C++, etc.) on Windows, you will need to

The following how-to guides are available in this category:

Only Orin (sm_87) / Jetpack 6 and later Tegra devices are supported.

By default, provisioned CI machines do not feature a GPU. See how to configure self-hosted runners if your feedstock needs access to additional resources like GPUs or long-running builds, and how to distinguish CPU and GPU jobs when your recipe builds both.

conda-forge has access to additional CI resources for feedstocks that can't build their packages in the default runners. Check Reference> Runners for a comprehensive list.

By default, feedstocks are created with support for the main platforms (e.g. linux-64, osx-64, win-64). Additional ones may be available in an opt-in fashion. The configuration can be changed manually in conda-forge.yml, or through automated migrations.

Sometimes a serious packaging error may be discovered once the packages are built and published.

It may happen that a security vulnerability is discovered in a version of a published package that

The conda-forge workflow assumes that contributors will always open their pull requests from their feedstock fork. Follow these best practices to make sure your branches are always up-to-date.

The conda-forge workflow assumes that a push to any branch in the feedstock repository will result in a build being uploaded to the conda-forge channel (and that's why PRs must always be opened from a fork!).

Sometimes you face the possibility of needing to package a fork.

Perhaps one of the hardest tasks of package maintenance is ensuring that the recipe specifies

Rerendering is the process of regenerating the templated contents of your feedstock, according to the contents of conda-forge.yml and the recipe itself.

Some parts of the conda-forge automation are exposed as "bot commands" that can be invoked from issue titles and comments. You can check the full list in the admin-web-services documentation.

There are cases when you wish to update a dependency in a number of packages that were already built

Recipes for packages that depend on the CUDA Toolkit typically are more complicated compared

What to expect

Despite having a successful build, sometimes we can't run all the tests we'd like on CI. Some reasons include:

The first thing that you should know is that you can locally test Windows