To add some additional information to what's already on this thread: PYTHON-1378 is actively being looked into. An initial look has suggested a likely cause; it's very likely this was an oversight stemming from the move to cibuildwheel. Assuming I can confirm that a fix will then be provided. All of that work will be managed on PYTHON-1378.
Regarding the question about asyncore vs. asyncio: as Jarek correctly pointed out we have PYTHON-1375 to represent the work of moving to asyncio. I'll also mention that we've begun defining what will be included in the next Python driver release. Let's call it 3.30.0, although (as always) that's subject to change. This release is currently slated to include three major changes: * Stabilize asyncio reactor and make it the default (PYTHON-1375 <https://datastax-oss.atlassian.net/browse/PYTHON-1375>) * Officially get off nose and move to pytest (PYTHON-1297 <https://datastax-oss.atlassian.net/browse/PYTHON-1297>) * Extend vector support to variable length types (PYTHON-1369 <https://datastax-oss.atlassian.net/browse/PYTHON-1369>) As mentioned above everything is subject to change but as of this writing the current plan is that PYTHON-1375 will be included in the next release. This can be tracked via the "Fix version" on the various tickets above (yup, we already have a 3.30.0 release in JIRA). You can also follow along on the Python driver mailing list <https://groups.google.com/a/lists.datastax.com/g/python-driver-user>; I'll likely be starting a more detailed discussion on some of these points there soon. Thanks! - Bret - On Wed, Feb 21, 2024 at 7:58 AM Jarek Potiuk <ja...@potiuk.com> wrote: > This is cool - thanks Jeff for this explanation, that helps us in making > informed decisions. Really appreciate it! > > Very encouraging for the future :) - I think then, if the donation is > on-going, choosing a cassandra-driver (which I understand will become > ASF-owned) is definitely a preference for us. > > And no - we do not have to release it now. We can definitely wait - we can > just exclude Python 3.12 support until the .whl has libev support (I hope > my issue will be handled soon by Datastax :). Then we can re-enable Python > 3.12 support and add instructions to our users to make sure libev is > included on Python 3.12. So it does not block us now, and we have > clear vision on the way forward. > > BTW. I looked at the links - they were mostly about Java Driver and > mention Python Driver as the next logical step (agree) - is there anything > happening currently with it ? There is a doc link that I have no access to, > but would be great to know when it might happen? I am just eager to see it > happen. > > J. > > On Wed, Feb 21, 2024 at 12:53 PM Jeff Jirsa <jji...@apache.org> wrote: > >> >> >> On 2024/02/21 09:26:53 Jarek Potiuk wrote: >> > Hello dear Cassandra community, >> > >> > I am a fellow PMC member of Apache Airflow and recently we started to >> look >> > at the Cassandra provider of ours in the context of Python 3.12 >> migration >> > and the integration raised my interest. >> > >> > TL;DR; I am quite confused, which client should we use to be >> future-proof >> > and I would appreciate the advice of the community on it, also I would >> like >> > to understand why there is no community-managed client, as seems that >> with >> > the current approach, any Python project (including ASF ones are pretty >> > much forced to use 3rd-party managed way to use Cassandra, which I find >> > rather strange. >> > >> > Context: >> > >> > So far in Apache Airflow we were using >> > https://github.com/datastax/python-driver/ to connect to Cassandra, but >> > when we worked on Python 3.12 compatibility. While looking at it, I >> > discovered something strange >> > >> >> Mid-donated to the foundation: >> >> CEP: >> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+Datastax+Drivers+Donation >> >> [Private@]: >> https://lists.apache.org/thread/gor4b5l1hc4yokmcmpnhkfvg52w7rpp0 >> >> Status in board report: >> https://apache.org/foundation/records/minutes/2023/board_minutes_2023_08_16.txt >> >> The Scylla version is a fork WITH ADDITIONS that work with implementation >> details of Scylladb not present in Apache Cassandra. >> >> Preference use "Datastax" driver under donation if at all possible, and >> get it fixed as rapidly as is practical, but given that Scylla has already >> fixed the issue in theirs and it's an apache licensed fork of the same >> code, if you have to ship something to remain functional, that seems like a >> reasonable fallback. >> >> >> >> >> >>
