Migrator for win-arm64 uses incorrect dependency graph

[h-vetinari]

Looking at the status page for the migrator, a few unexpected packages show up. For example, the migrator seems to think that conda-forge-ci-setup still depends on pypy

However, the conda-forge-ci-setup recipe has never depended on pypy-meta (can be verified by running git log -S pypy-meta -- recipe/meta.yaml in the ci-setup repo).

Similarly, the bot seems to think that conda depends on rapidfuzz (though no mention of that can be found in the recipe), which pulls in numpy and the whole LAPACK stack

CC @beckermr @isuruf @baszalmstra

[beckermr]

This is likely the usual mix of odd edges in the graph from various meta packages that we use to swap things in and out.

[h-vetinari]

I could maybe understand that for pypy, but how can conda show up as a child of rapidfuzz? There are no metapackages involved in the latter situation, AFAICT.

[beckermr]

I'm continually surprised by the conda-forge graph. Many times it is not a bug but is instead some obscure edge case.

[h-vetinari]

I don't understand how such an edge case could even look like. I mean, yes, different kinds of dependencies (build/host/run/test) are one thing, but I'm thoroughly confused how something can be considered a direct dependency of conda (IOW rapidfuzz listing conda under "Immediate children"), despite no mention of it in the conda recipe whatsoever.

[isuruf]

"Immediate child" here means "direct dependency or a direct dependency of a noarch immediate child".

conda -> conda-smithy (downstreams test) -> grayskull (test) -> rapidfuzz

[beckermr]

The graph never ceases to amaze!

If we are skipping tests for this migration, we can adjust how the graph edges are computed in this bit of code to remove test deps.

Right now the code adds back edges for all deps when probably we just need build+host+run.

[h-vetinari]

Thanks for the explanation @isuruf! I think it would make sense to remove the test deps from the graph for the win-arm migration (at least those test deps that come from noarch feedstocks!). We shouldn't need to build numpy (and the BLAS stack) to bootstrap the build tools.