Migrator bot opens PRs ignoring number of children?

[h-vetinari]

There are open PRs in the 3.13 migration with 0(!) children, while feedstocks with >2000 children are awaiting PR. This seems quite suboptimal as a strategy, if we don't tackle the biggest bottlenecks the earliest.

Bottom of the table filtered to "In PR" currently looks like this:

[h-vetinari]

Actually, it seems to disregard dependencies at least in some cases? It opened a PR for numpy without ever opening a PR for cython, even though numpy depends on that explicitly.

CC @beckermr

[jakirkham]

It's worth noting we needed to pause the migrator¹ due to an absence of cross-python²

1: conda-forge/conda-forge-pinning-feedstock#6361
2: conda-forge/cross-python-feedstock#79

[h-vetinari]

I know, but that has no bearing on this issue.

[beckermr]

Yeah I have no idea here. Someone will have to load the thing and look at the graph. I won't get to it for a while, but feel free to go ahead.

[beckermr]

So numpy is marked as part of a cycle in the graph for python. See this file and this entry

 "cycles": {
   "__set__": true,
   "elements": [
    "fenics-basix",
    "fenics-basix-meta",
    "gnuradio",
    "gnuradio-soapy",
    "heavydb-ext",
    "intel-compiler-repack",
    "numpy",
    "omniscidb",
    "pyopencl"
   ]
  },

Feedstocks in cycles always go first no matter what. The surprising thing is that the solver checks passed.

[beckermr]

The bot also skips solver checks for nodes in cycles. So this PR is expected.

[beckermr]

The final bit here is that the bot only opens PRs for things it can solve. So even if it tried a feedstock with more downstream packages, if that one does not solve, it will not make the PR. This explains the rest of the things. I am going to close this issue. Feel free to reopen!

[h-vetinari]

So numpy is marked as part of a cycle in the graph for python.

That seems spurious, numpy shouldn't depend on any of these (I guess there's a longshot that it relies on intel repack through lapack and MKL).

Also, omniscidb is archived, so presumably shouldn't be part of any cycle calculations...

[h-vetinari]

I mixed up the intel feedstocks; the intel-compiler-repack at least has a spurious python dependency, which at least explains why the bot wants to build it for various pythons. We just need to add a * there IMO.

[beckermr]

numpy in a loop is real. here is what the graph says:

intel-compiler-repack 
 pred: ['pyopencl'] 
 succ: ['numpy']
numpy 
 pred: ['intel-compiler-repack'] 
 succ: ['pyopencl']
pyopencl 
 pred: ['numpy'] 
 succ: ['intel-compiler-repack']

(edit: printed the cycle from the wrong graph)

The intel-compiler-repack feedstock has a test that depends on pyopencl:

https://github.com/conda-forge/intel-compiler-repack-feedstock/blob/ef8dbff1a48f66ef87660d9059d003f4e00fe68e/recipe/meta.yaml#L303-L314