Pin flexparser to <0.4

[ndevenish]

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.

See discussion in hgrecco/pint#1969 (comment)

The release of flexparser 0.4 has effectively "Backported" 😉 Python 3.13 failures to Python 3.12. This fixes the pinning for the current release and anyone pinning to this version of pint, this pin can be removed for the as-yet-unreleased next pint release.

[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 almost always follow the syntax in our documentation. For the host section of the recipe, you should almost always use python {{ python_min }}.* for the python entry. You may need to override the python_min variable if the package requires a newer Python version than the currently supported minimum version on conda-forge.
• noarch: python recipes should almost always follow the syntax in our documentation. For the run section of the recipe, you should almost always use python >={{ python_min }} for the python entry. You may need to override the python_min variable if the package requires a newer Python version than the currently supported minimum version on conda-forge.
• noarch: python recipes should almost always follow the syntax in our documentation. For the test.requires section of the recipe, you should almost always use python ={{ python_min }} for the python entry. You may need to override the python_min variable if the package requires a newer Python version than the currently supported minimum version on conda-forge.

[ndevenish]

I'm reluctant to address the new linting issues in this PR, suggest leaving for the imminent pint version update

[jan-janssen]

@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/11721377498.}

[ndevenish]

Oh, this is slightly more complicated. This pint fails on 3.13 so needs to be restricted for build

[conda-forge-admin]

Hi! This is the friendly conda-forge automerge bot!

I considered the following status checks when analyzing this PR:

• linter: passed
• azure: passed

Thus the PR was passing and merged! Have a great day!

[ndevenish]

Ah, me being dumb. Your commit did that restriction but I hadn't refreshed github so the pass didn't show.

[stefdoerr]

Hi I see your fix on conda but conda install doesn't seem to pick it up. Is there some delay before the conda-forge indexes are updated?

The following package could not be installed
└─ pint ==0.24.3 pyhd8ed1ab_1 does not exist (perhaps a typo or a missing channel).

[jan-janssen]

Yes, typically it takes about 30 minutes for the package to be available for download. It has something to do with the content delivery network anaconda is using.

[ndevenish]

I've added a PR for older 0.24.* builds to conda-forge/conda-forge-repodata-patches-feedstock#900.