FEAT: add support for automatic abi3 version selection
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 Report
:x: Patch coverage is 37.50000% with 5 lines in your changes missing coverage. Please review.
:white_check_mark: Project coverage is 74.61%. Comparing base (df08a28) to head (7dd3d6d).
:warning: Report is 13 commits behind head on main.
| Files with missing lines | Patch % | Lines |
|---|---|---|
| extension_helpers/_utils.py | 37.50% | 5 Missing :warning: |
Additional details and impacted files
@@ Coverage Diff @@
## main #132 +/- ##
===========================================
+ Coverage 58.31% 74.61% +16.30%
===========================================
Files 4 4
Lines 379 386 +7
===========================================
+ Hits 221 288 +67
+ Misses 158 98 -60
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
:rocket: New features to boost your workflow:
- :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
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.
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.
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.
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.
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