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.
>>>
>>>
>>>
>>>
>>>
>>>

Reply via email to