Hi, I would like to propose adding support for PEP 803 abi3t as a build target.
This would allow downstream (most notably matplotlib) to start testing Python pre-releases early and without needing to build their dependencies too, as well as future-proof the package's set of published artifacts for compatibility for future versions, eliminating the need for a new release each cycle.
In principle, this could be achieved in stages:
- support abi3 as a build target
- publish abi3 nightlies
- publish abi3 wheels to PyPI (in addition to version-specific ones)
- support abi3t as a build target
- publish abi3t nightlies
- publish abi3t wheels to PyPI (in addition to version-specific ones)
Long term, granted the impact on performance is measured and considered acceptable, it could also make sense to stop shipping version-specific wheels altogether; retaining the ability to build them as needed, in particular for downstream re-packagers, as long as targeting stable ABIs is implemented as an opt-in (rather than an opt-out).
I have not studied the feasibility for this specific package yet, I'm just asking whether this seems like a goal worth pursuing for maintainers.
In my, perhaps limited experience, I don't think I've encountered a situation where this idea wasn't applicable, so it seems worth asking.
Thank you!
Hi, I would like to propose adding support for PEP 803 abi3t as a build target.
This would allow downstream (most notably matplotlib) to start testing Python pre-releases early and without needing to build their dependencies too, as well as future-proof the package's set of published artifacts for compatibility for future versions, eliminating the need for a new release each cycle.
In principle, this could be achieved in stages:
Long term, granted the impact on performance is measured and considered acceptable, it could also make sense to stop shipping version-specific wheels altogether; retaining the ability to build them as needed, in particular for downstream re-packagers, as long as targeting stable ABIs is implemented as an opt-in (rather than an opt-out).
I have not studied the feasibility for this specific package yet, I'm just asking whether this seems like a goal worth pursuing for maintainers.
In my, perhaps limited experience, I don't think I've encountered a situation where this idea wasn't applicable, so it seems worth asking.
Thank you!