Bot Cannot Handle Updates for URLs that depend on Conda Build Config Variants

[ytausch]

We currently use a rather complex recipe for the polars-feedstock which does have a source URL which is dependent on a conda_build_config.yaml variable.

Permalink: Recipe

The logic in conda_forge_tick.update_recipe.version._try_to_update_version and conda_forge_tick.update_recipe.version.update_version fails to process this recipe correctly.

I've looked into the code a bit and think that the problem is that we simply do not support different source URLs that directly or indirectly depend on conda build config variants yet.

There should be a fix or at least a workaround for that.

[isuruf]

Using one feedstock to merge three separate packages into one recipe is not how feedstocks are supposed to be used. Please use three separate feedstocks as I mentioned in the PR that made this change.

[ytausch]

@0xbe7a

[0xbe7a]

The three outputs only differ by their used build flags. I think using three different feedstocks for this is overly redundant and enables drifting build configs.

[beckermr]

The best way to proceed here is to add a test case to the bot and see what happens. The bot is capable of updating recipes whose sources depend on selectors. I am betting there is a way to change the recipe to make it work with the bot. It may be possible to have the bot account for the conda-build-config.yaml, but I am betting this is non-trivial.

Notes on the version migrator algorithm are here: https://github.com/regro/cf-scripts?tab=readme-ov-file#notes-on-the-version-migrator.

[ytausch]

Test cases added in #2836.

The bot is capable of updating recipes whose sources depend on selectors.

I guess the problem currently is to set name conditionally then? Because this clearly fails.

[beckermr]

Right so the bot cannot handle jinja2 if statements.

[ytausch]

Workaround in conda-forge/polars-feedstock#243