fix: use python_min in skip conditions for noarch Python recipes

[janjagusch]

Summary

Per CFEP-25 standards, V1 noarch Python recipes only define python_min in their variant configuration, not python. This PR fixes the V0→V1 recipe conversion to use python_min instead of python in skip condition match expressions for noarch Python packages.

Changes

• Added _is_noarch_python() helper method to detect noarch: python recipes
• Modified _upgrade_selectors_to_conditionals() to use python_min for noarch Python recipes
• Added test case with noarch-python-skip.yaml fixture

Before

build:
  skip: match(python, "<3.10")
  noarch: python

After

build:
  skip: match(python_min, "<3.10")
  noarch: python

Related Issues

• Fixes V1 conversion should use python_min instead of python in skip conditions for noarch Python recipes #479
• Downstream issue in grayskull: skip: match(python, ...) should use python_min for v1 noarch recipes grayskull#644
• Downstream PR in cf-scripts: Fix dep_updates for v1 recipes using python_min conda-forge/conda-forge-bot#5306

Test Plan

• Added unit test noarch-python-skip.yaml that verifies the fix
• Verified existing selector-match-upgrades.yaml test still passes (non-noarch recipes still use python)
• All 34 tests in test_recipe_parser_convert.py pass

---

This PR was generated with the assistance of Claude Code

[schuylermartin45]

Apologies for the slow response on this, I have been absolutely swamped by other work lately.

At first glance I think this is a great change and I really appreciate the contribution! However I think this may be specific to how conda-forge operates and not necessarily how everyone in the wider Conda Community operates. We try to keep Conda Recipe Manager and its tooling accessible for all Conda users.

The way we've handled this in the past is to offer additional flags to crm convert (or whatever crm * CLI command(s) apply to the situation). That way, all members of the Conda Community can use the tooling as they see fit.

Once a flag is added to crm convert, you can take advantage of the RecipeReaderFlags class/enum to trickle that option down to the RecipeParserConvert class.

Let me know if that sounds like a good plan. Thanks!

[janjagusch]

Apologies for the slow response on this, I have been absolutely swamped by other work lately.

At first glance I think this is a great change and I really appreciate the contribution! However I think this may be specific to how conda-forge operates and not necessarily how everyone in the wider Conda Community operates. We try to keep Conda Recipe Manager and its tooling accessible for all Conda users.

The way we've handled this in the past is to offer additional flags to crm convert (or whatever crm * CLI command(s) apply to the situation). That way, all members of the Conda Community can use the tooling as they see fit.

Once a flag is added to crm convert, you can take advantage of the RecipeReaderFlags class/enum to trickle that option down to the RecipeParserConvert class.

Let me know if that sounds like a good plan. Thanks!

Thanks for the pointer, @schuylermartin45. I must admit I wasn't aware that CRM provides tooling for the whole Conda community, and not just Conda-Forge. I'll try to look into your suggestion this week. :)