Add freethreading support

[isuruf]

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.

matplotlib has wheels in latest release

[isuruf]

@conda-forge-admin 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.

[tacaswell]

To be clear, this is adding the build options for freethreading, not claiming mpl is freethreading safe?

[dopplershift]

What does "freethreading safe" mean?

[ngoldbaum]

To be clear, this is adding the build options for freethreading, not claiming mpl is freethreading safe?

This is building binaries that support the new CPython ABI under the free-threaded build. This is related but orthogonal to supporting free-threading.

You need to explicitly declare that matplotlib's extension modules don't use the GIL to mark matplotlib as thread-safe.

What does "freethreading safe" mean?

Good question! The working definition we've been going with is that you should have similar thread safety guarantees under the GIL-enabled and GIL-disabled build. So any assumptions made in low-level code about the GIL providing locking and making it OK to do things like use C global statics to store module state are no longer OK and all that stuff should be fixed.

However there are lots of other thread safety issues in Python codebases that are unrelated to the GIL, I don't think the presence of any of those issues means a module is "unsafe" under freethreading.