Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drop the capsule ABI #47

Open
ZeroIntensity opened this issue Jan 7, 2025 · 2 comments
Open

Drop the capsule ABI #47

ZeroIntensity opened this issue Jan 7, 2025 · 2 comments
Labels
feature New feature or request package This has to do with the packaging or distribution of PyAwaitable

Comments

@ZeroIntensity
Copy link
Owner

Proposal:

Capsules are horrible. They complicate the distribution process, and apparently make it difficult for things that use scikit-build-core or other non-setuptools build systems to use the library. See #30 (comment)

This will include bumping pyawaitable's major version to 2.

The better approach would be to do a few things, with more automation in the release process:

  • Completely drop the initialization functions (for managing references, we should hook onto our own module).
  • We'll continue shipping a vendorable copy, but the main distribution mechanism will be via a header file that contains static functions.
  • For ctypes compatibility, we can maybe autogenerate a capsule, or probably just expose some symbols on pyawaitable's shared extension.
@ZeroIntensity ZeroIntensity added feature New feature or request package This has to do with the packaging or distribution of PyAwaitable labels Jan 7, 2025
@AraHaan
Copy link
Collaborator

AraHaan commented Jan 8, 2025

I feel like we should not worry about users of ctypes or those wanting to use pyawaitable outside of their own C extension code. I think distributing only a pyawaitable.c and the current pyawaitable.h file that currently gets shipped with the pip version with a few changes would be better for both vendoring and normal usage (the vendor file would contain both the c and the header file for usage int their own compilation).

Doing it like this where the vendor is 2 files and we only ship a single distribution of the codebase on releases makes it easier in the long run I believe.

Also the best part is, the zipfile module could be used to zip up the resulting pyawaitable.c and the header file for distribution on v2 as well. I also feel like v2 should wait until Python 3.9 is End of Life to then strip the Python 3.9 support and go to the code that is in the feature branch that prefers PyType_GetSlot for all the access to the slots in all type objects due to working for them all in Python 3.10 and newer so only supporting 3.10 or newer on version 2 of PyAwaitable would be very fitting. Sadly it is only about 9 months away until then.

@ZeroIntensity
Copy link
Owner Author

We do have to worry about ctypes, because we are one of them--our test suite is written around the ctypes bindings. We also aren't shipping a pyawaitable.c either; solely a pyawaitable.h that contains the entire implementation in static functions will be shipped.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request package This has to do with the packaging or distribution of PyAwaitable
Projects
None yet
Development

No branches or pull requests

2 participants