>From the "Supported upgrade path for 4.0" discussion, it seems like there was consensus around supporting the "3.0 -> 4.0" upgrade path as well (in addition to 3.11 -> 4.0), so we may need to add python3 support for 3.0 as well?
Internally. we had a need to make 3.0 cqlsh python3 compatible, and I ended up backporting trunk pylib, cqlsh, cqlsh.py for python3 support and reverted https://issues.apache.org/jira/browse/CASSANDRA-14825 (this backport is currently being tested). Haven't assessed the impact on dtest environment yet. This approach was much less effort vs cherry-picking individual changes, but involves probably equal or more testing effort. If we decide to add python3 support for 3.0, I am happy to contribute this once we have enough confidence from testing (but unsure if we have the appetite for this big a change in 3.0). On Thu, Jan 28, 2021 at 3:01 AM Benjamin Lerer <benjamin.le...@datastax.com> wrote: > Considering the issue with pip. I agree that we should remove support for > 3.0 and ensure that python 3 is supported by 3.11. > > On Wed, Jan 27, 2021 at 8:18 PM Jonathan Ellis <jbel...@gmail.com> wrote: > > > Python 2 was EOLed over a year ago. I think it's fine to (1) require > > python 3 to run cqlsh and (2) remove code that supports python 2 whenever > > it's convenient. > > > > Angelo has the right idea that rather than trying to finesse a > deprecation > > cycle into 4.0 at this late date, a better migration path can be provided > > by backporting python3 support to 3.11. > > > > On Wed, Jan 27, 2021 at 12:36 PM Brandon Williams <dri...@gmail.com> > > wrote: > > > > > On Wed, Jan 27, 2021 at 12:09 PM Adam Holmberg > > > <adam.holmb...@datastax.com> wrote: > > > > I want to emphasize here: to my way of thinking, "dropping support" > at > > > this > > > > juncture is just a matter of documenting it, and maybe introducing a > > > > warning. We don't need to *remove* support for python2. It will > > continue > > > to > > > > work as-is. This would just guide us in deciding whether to work on > > flaws > > > > that are python2-specific, and whether new things are developed with > > > > backwards compatibility as a forcing concern. > > > > > > Actually, I think we have to go a little bit further, and at least as > > > far as packaging is concerned, remove support for python2. Recently > > > pip updated to 21.0 and removed python2 support, which broke any > > > builds that built artifacts requiring pip. We now pin pip: > > > > > > > > > https://github.com/apache/cassandra-builds/commit/54c45a9bcf9b36a3f78b7d773eaf1067483b49b8 > > > to get around this, but highlights that we too need to move away from > > > anything using python2. So while we would not modify code to *remove* > > > python2 support, you would have to invoke python2 on the code in your > > > own way, since the packages would depend on python3. > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > > -- > > Jonathan Ellis > > co-founder, http://www.datastax.com > > @spyced > > >