You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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:
static
functions.ctypes
compatibility, we can maybe autogenerate a capsule, or probably just expose some symbols on pyawaitable's shared extension.The text was updated successfully, but these errors were encountered: