Add migration system

[JaydenGrubb1]

Added a migration utility vinca-migrate for migrating the pinned system dependencies to newer versions. The utility also modifies the specified vinca.yaml to trigger a rebuild of the affected packages (this feature will require a bit more work as it does not know what packages are supported). To run the utility you must specify the path to the pinnings file.

vinca-migrate .ci_support/conda_forge_pinnings.yaml

Optionally, also specify --dry-run to leave the files untouched, or --pinnings-only to skip the affected packages check.

[Tobias-Fischer]

Hi @wolfv - do you have time to review? @JaydenGrubb1 is one of my students just finishing off his project, and this + #59 are his main deliverables.

[Tobias-Fischer]

Hi @traversaro - this might come in handy; do you have time to take a look? Not urgent at all :)

[Tobias-Fischer]

Actually it just occurred to me that we need the new conda_build_config.yaml with rattler-build first I guess

[traversaro]

Actually it just occurred to me that we need the new conda_build_config.yaml with rattler-build first I guess

Yes, I guess that is the case.

However, just to understand, what is the proposed workflow of this tool? You manually update the .ci_support/conda_forge_pinnings.yaml file coping it from conda-forge-pinnings (and eventually fixing it, if they are some migrations that are good stage that we want to use it) and then the tools understand which packages should be rebuilt, and add them to vinca_*.yaml file?

If I got this right, something that I am not sure in love with is the idea of specifying wich packages to rebuild by "removing" packages from the vinca_**.yaml. The problem there is that then on a rebuild is never clear which package we should add, and it would be great if we could separate somehow the packages that we support in robostack, from the packages that a given moment we want to rebuild. However, I do not have a concrete proposal on this, so I may need to think about this.