Debug main, do we see the same failure?

[xhochy]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

[xhochy]

Same failure here :(

[xhochy]

@jaimergp I think I found a bug in conda-libmamba-solver=24.7.0, but I don't know how I can provide more useful information. The rust package on osx-* is simply not found in the testing phase. The only diff I can find that remotely has to do with this is conda/conda-libmamba-solver#485

[mbargull]

Could be virtual package handling, but could also be caching related, i.e., conda/conda-libmamba-solver#482 .

[pkgw]

@xhochy Nice investigation! Thanks for digging into this.

[jaimergp]

Thanks for the report. Is it ok if I debug things in your branch directly? Thinking of creating a couple of conda-libmamba-solver branches with a couple reverts to see which one is the culprit.

[jaimergp]

Could be virtual package handling, but could also be caching related, i.e., conda/conda-libmamba-solver#482 .

We are supposedly not using .solv files during channel reloads but maybe there's a bug in that logic too 😬

[xhochy]

Thanks for the report. Is it ok if I debug things in your branch directly? Thinking of creating a couple of conda-libmamba-solver branches with a couple reverts to see which one is the culprit.

Yes, feel free to push freely here.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found some lint.

Here's what I've got...

For recipe/meta.yaml:

• Selectors are suggested to take a <two spaces>#<one space>[<expression>] form. See lines [62]

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

[jaimergp]

Trying conda/conda-libmamba-solver@8ed9689, no solv files at all.

[jaimergp]

That didn't change much. Trying conda/conda-libmamba-solver@610422c, which brings conda/conda-libmamba-solver#485 back.

[jaimergp]

Well, same story. I really wonder if this is it? conda/conda-libmamba-solver@63c545f

[jaimergp]

No way 😂 Why!

[jaimergp]

Let's see what the difference is with deduplicated channels or not. I suspect there's some bug in the Channel object in conda, where the "identity" of the channel might not consider the subdir or something like that, so it gets deduped, but wrongly so.

[jaimergp]

The list of channels (and their URLs) are indeed identical, so I'm clueless why deduplication affects the reloading. My guess is that there might be some sort of race condition when they are reloaded rapidly in succession, so loading them twice in a row would help with the Python objects getting updated. I've added a sleep(1) statement to see if that helps.

[jaimergp]

Ah wait, in one of the cases we see this:

file:///Users/runner/miniforge3/conda-bld/noarch
 > file:///Users/runner/miniforge3/conda-bld/noarch
file:///Users/runner/miniforge3/conda-bld/osx-64
 > file:///Users/runner/miniforge3/conda-bld/osx-64
 > file:///Users/runner/miniforge3/conda-bld/noarch
https://conda.anaconda.org/conda-forge/osx-64
 > https://conda.anaconda.org/conda-forge/osx-64
 > https://conda.anaconda.org/conda-forge/noarch
---
file:///Users/runner/miniforge3/conda-bld/noarch
 > file:///Users/runner/miniforge3/conda-bld/noarch
https://conda.anaconda.org/conda-forge/osx-64
 > https://conda.anaconda.org/conda-forge/osx-64
 > https://conda.anaconda.org/conda-forge/noarch

The osx-64 subdir is missing in the first channel (but not in the second), so it gets lost after deduplication. I think deduplication should be done on URLs not Channels. And this is done internally with explicit subdirs, BUT turns out that Channel.urls() silently ignores the subdirs keyword if Channel.platform is defined. Great.

[jaimergp]

Published conda/conda-libmamba-solver#531 which will be released with 24.9.

[pkgw]

Thanks for hunting this down @jaimergp!

[jaimergp]

Thanks for the reports! I think we can close this one, right? main is working after all. Once 24.9 we can revert the conda-forge.yml changes.

[xhochy]

Thank you for the effort 😍