Migrations

For dependency resolution and CI workflow snippet generation, rather than hard-code dependencies, often we prefer “migration” files, as discussed in the knowledge base. Most commonly these define version constraints, and are conda smithy rerender’d to ensure maximum compatibility.

Instead of using the upstream variants, these may also be defined by hand. For instance, consider handling an update to PyTorch 2.9 (e.g. from this GROMACS metatomic package):

1# .ci_support/migrations/pytorch29.yaml
2__migrator:
3  build_number: 1
4  kind: version
5  migration_number: 1
6libtorch:
7- '2.9'
8pytorch:
9- '2.9'

Which can be applied to a package outside the conda-forge ecosystem via:

1conda smithy rerender