FEAT: add support for automatic abi3 version selection

[neutrinoceros]

This is at a proof-of-concept stage: I haven't bothered writing tests for it yet, but I wanted to bring it up because I always feel like this feature is missing, and while complicated to implement right in the general case, it so happens that I wrote a small library that already does the heavy lifting needed to determine whether it is safe to build abi3 binaries in a portable fashion, so, before I commit more time to it, does it sound worth an extra dependency to others ?

[codecov]

Codecov Report

❌ Patch coverage is 40.00000% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 75.25%. Comparing base (812dd04) to head (219c3f7).
⚠️ Report is 5 commits behind head on main.

Files with missing lines	Patch %	Lines
extension_helpers/_utils.py	40.00%	6 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #132      +/-   ##
==========================================
- Coverage   75.46%   75.25%   -0.21%     
==========================================
  Files           4        4              
  Lines         379      388       +9     
==========================================
+ Hits          286      292       +6     
- Misses         93       96       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[astrofrog]

I'm not super keen on having an auto mode because it's usually good to be specific about whether one expects abi3 wheels or not, otherwise a package could silently start switching to non-abi3 wheels due to some issue with the interpreter or runtime_introspect.

However if others are keen on this I think we should make runtime_introspect an optional dependency.

[neutrinoceros]

otherwise a package could silently start switching to non-abi3 wheels due to some issue with the interpreter or runtime_introspect.

Fair point. It should be easy enough to distinguish two auto modes actually:

• "always": auto set the version and fail explicitly if not possible
• "prefered": this corresponds to what I implemented first; auto set the version but silently fall back to non-abi3 if not possible

Would that work better for you ?
My main motivation is to make this env var usable unconditionally, even when incompatible free threading builds are included in a build matrix.

[neutrinoceros]

Also, if PEP 809, or something similar, gets accepted, we could be facing the need to build more than one limited-api wheel per package as soon as next year. In which case, hard coding the target version, as is the only supported option now, would force users to build (temporary) additional logic to work around it.

[neutrinoceros]

btw, in case it helps, there is now a semantic distinction between the two possible falsy outputs:

• False means that we know for sure the Limited API is not supported (you'd get this with CPython 3.13t or 3.14t)
• None means "not sure", and basically indicates that it's time to patch and upgrade runtime-introspect

meanwhile, True is only ever returned in case support is established with certainty (that's the intended behavior any way). I'm being extremely thorough in my testing approach for this library, so I feel I can confidently say that, while false negatives are possible (but should be reported and fixed), false positives should never happen.

[neutrinoceros]

There could be an even more explicit dichotomy:

• "match-runtime": unconditionally use the runtime version as the target.
• "match-runtime-if-supported": fallback to a version specific abi if needed (requires runtime-introspect)

@astrofrog let me know what you think

[neutrinoceros]

I rewrote this to use pypa/packaging instead of my one-man-show package. Hopefully this alleviate worries around future maintenance. It should also be easy to extend to support PEP 803 when pypa/packaging#1099 lands.