Repository navigation
FEAT: add support for automatic abi3 version selection - #132
neutrinoceros wants to merge 1 commit into
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #132 +/- ##
==========================================
- Coverage 76.61% 74.29% -2.32%
==========================================
Files 4 4
Lines 402 428 +26
==========================================
+ Hits 308 318 +10
- Misses 94 110 +16 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
bd0bcf1 to
34cd182
Compare
|
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 |
Fair point. It should be easy enough to distinguish two auto modes actually:
Would that work better for you ? |
|
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. |
1 similar comment
This comment has been minimized.
This comment has been minimized.
34cd182 to
7dd3d6d
Compare
| if py_limited_api is not None: | ||
| if py_limited_api == "auto": | ||
| fs = runtime_feature_set() | ||
| if fs.supports("py-limited-api"): |
There was a problem hiding this comment.
btw, in case it helps, there is now a semantic distinction between the two possible falsy outputs:
Falsemeans that we know for sure the Limited API is not supported (you'd get this with CPython 3.13t or 3.14t)Nonemeans "not sure", and basically indicates that it's time to patch and upgraderuntime-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.
|
There could be an even more explicit dichotomy:
@astrofrog let me know what you think |
7dd3d6d to
219c3f7
Compare
|
I rewrote this to use |
|
update: this is blocked by pypa/setuptools#5193 |
|
upstream blockers are both released. I'll take another look now to see how I can undraft it |
8ae8317 to
1a2d8de
Compare
I took this remark in consideration in updating the patch. Now opting-in auto-mode within a context that doesn't support it will raise an exception instead of silently falling back to version-specific abi tagging. Please let me know if you think this approach is viable. |
1a2d8de to
476e571
Compare
|
looking at changes in setuptools 84.2.1, I'm not sure I want to pursue this. Getting it right might be more difficult than I thought and would quickly stop being worth the effort, assuming it ever was |
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 ?