MNT: Use Jinja2 set statement for python_min

[matthewfeickert]

• Using a Jinja2 set statement for the python_min allows for all the build metadata to be contained in the recipe/meta.yaml and for recipe/conda_build_config.yaml to be removed.
• Bump build number.

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• [N/A] 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.

[matthewfeickert]

@conda-forge-admin, please rerender

[conda-forge-admin]

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.

I do have some suggestions for making it better though...

For recipe/meta.yaml:

• ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
  • For the host section of the recipe, you should usually use python {{ python_min }} for the python entry.
  • For the run section of the recipe, you should usually use python >={{ python_min }} for the python entry.
  • For the test.requires section of the recipe, you should usually use python {{ python_min }} for the python entry.
  • If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

[matthewfeickert]

cc @jonas-eschle this is an easier way than what I showed in PR #28.

[matthewfeickert]

Need to figure out why the linter message won't go away though.

[matthewfeickert]

• If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

Ah, I think conda-smithy is only checking if python_min is newer than the map value of python_min in .ci_support/linux_64_.yaml. That's not what I care about though (for this PR), I want it to be the oldest possible value that corresponds to

[project]
...
requires-python = ">=3.7"

in the Python package's pyproject.toml, which may also be a Python version dropped from conda-forge global pinning support.

[jonas-eschle]

cc @jonas-eschle this is an easier way than what I showed in PR #28.

Thanks for the ping, yes, looks preferrable

[matthewfeickert]

Once conda-forge/conda-smithy#2132 is merged this can get rerendered and then should be good to go.

[matthewfeickert]

conda-forge/conda-smithy#2132 is merged, but we need to wait for conda-smithy release v3.44.4 with the fix in there.

[matthewfeickert]

@conda-forge-admin, please rerender

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-webservice.

I tried to rerender for you, but it looks like there was nothing to do.

_{This message was generated by GitHub actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/11867831670.}

[matthewfeickert]

@conda-forge-admin, please rerender

[conda-forge-admin]

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.