Missing migrations for libavif pinned in conda-forge pinnings?

[traversaro]

Comment:

I was debugging some strange resolutions that boiled down to:

C:\Users\straversaro>conda create -n test "pygame>=2.5.2" "ffmpeg>=6.1.1" "libavif>=1.0.1"
Channels:
 - robostack-staging
 - conda-forge
Platform: win-64
Collecting package metadata (repodata.json): done
Solving environment: failed

LibMambaUnsatisfiableError: Encountered problems while solving:
  - package pygame-2.5.2-py310hc90abf7_1 requires sdl2_image >=2.6.3,<3.0a0, but none of the providers can be installed

Could not solve for environment specs
The following packages are incompatible
├─ ffmpeg >=6.1.1  is installable with the potential options
│  ├─ ffmpeg 6.1.1 would require
│  │  ├─ aom >=3.7.1,<3.8.0a0 , which can be installed;
│  │  └─ svt-av1 >=1.8.0,<1.8.1.0a0 , which can be installed;
│  ├─ ffmpeg 6.1.1 would require
│  │  └─ aom >=3.8.1,<3.9.0a0 , which conflicts with any installable versions previously reported;
│  ├─ ffmpeg [6.1.1|7.0.0] would require
│  │  └─ aom >=3.9.0,<3.10.0a0 , which conflicts with any installable versions previously reported;
│  └─ ffmpeg 6.1.1 would require
│     └─ aom >=3.8.2,<3.9.0a0 , which conflicts with any installable versions previously reported;
└─ pygame >=2.5.2  is not installable because it requires
   └─ sdl2_image >=2.6.3,<3.0a0  but there are no viable options
      ├─ sdl2_image 2.6.3 would require
      │  └─ libavif >=0.11.1,<0.11.2.0a0 , which requires
      │     └─ aom >=3.5.0,<3.6.0a0 , which conflicts with any installable versions previously reported;
      └─ sdl2_image [2.6.3|2.8.0|2.8.2] would require
         └─ libavif >=1.0.1,<1.0.2.0a0  but there are no viable options
            ├─ libavif [0.11.1|1.0.1], which cannot be installed (as previously explained);
            ├─ libavif 1.0.1 would require
            │  ├─ aom >=3.7.0,<3.8.0a0 , which can be installed;
            │  └─ svt-av1 >=1.7.0,<1.7.1.0a0 , which conflicts with any installable versions previously reported;
            └─ libavif 1.0.1 would require
               └─ aom >=3.6.1,<3.7.0a0 , which conflicts with any installable versions previously reported.

Looking on why this was happening, I noticed that svt-av1 and aom migrations are happening here (see #31 and #30), but not on 1.0.1 that is the version pinned (https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/df20b4fdd33f4713f37a8ff6c6f9290accb55f51/recipe/conda_build_config.yaml#L460).

I guess the complex run_exports logic in this recipe is confusing the bot that is opening PRs in https://github.com/conda-forge/conda-forge-pinning-feedstock ?

fyi @conda-forge/libavif

[traversaro]

xref: conda-forge/gymnasium-feedstock#36 (comment)

[hmaarrfk]

the migration bot was stuck for a while s oa few migrations may have been skipped.

i felt like the avif migration finished quickly, so maybe it missed something.

can you try rerendering your package and seeing if that helps?

[carterbox]

@hmaarrfk, I think the issue that Silvio is trying to raise is that the channel pinning for libavif is 1.0.1, but migrations for svt_av1 and aom were applied to libavif=1.0.4. i.e. the channel pinning is behind or is too strict.

Probably the channel pinnings need to be moved or made less strict. e.g. libavif=1

[hmaarrfk]

ah i see..

[carterbox]

Thanks for reporting, @traversaro. Probably updated pinnings will fix the issue. In the mean time, you can use a local conda_build_config.yaml to override the channel-wide pinning.

[traversaro]

Thanks for the fast feedback!

[traversaro]

Just for completeness: I noticed this in particular on Windows as the pinned libavif==1.0.1 actually adds a run_exports on libavif==1.0.1, not libavif16 (see https://conda-metadata-app.streamlit.app/?q=conda-forge%2Fwin-64%2Flibavif-1.0.1-h7a9aacb_3.conda, issue fixed in #25), so beside the pinning update all packages that depends on libavif and have Windows builds need to be rebuilt (or the repodata info patched).

[hmaarrfk]

lets see if the new global pinning addresses this. please comment and let us know if this is resolved.

[traversaro]

lets see if the new global pinning addresses this. please comment and let us know if this is resolved.

Thanks, the new pinning + rebuilding packages on windows should work fine.