That all sounds great! Thanks for all the information Bret. On Wed, Feb 21, 2024 at 8:57 PM Bret McGuire <bret.mcgu...@gmail.com> wrote:
> 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. >>> >>> >>> >>> >>> >>>