Products.cmfplone: Drop Python 2 Support for Plone 6

[tisto]

PLIP (Plone Improvement Proposal)

When Plone 6 will be out, Python 2 will be officially unsupported. It does not make any sense if we ship a major Plone version with Python 2. With the current schedule, we will ship Plone 6 one year after Python 2 is unsupported.

Responsible Persons

Timo Stollenwerk

Seconder:

Abstract

Drop support for Python 2 on the next major Plone version (Plone 6).

Motivation

Maintaining two Python versions has major downsides. We have lots of conditional imports and try/exept, if/else statements all over the place that are hard to maintain and debug. We should focus on areas where it makes more sense.

Assumptions

Python 2 will not be supported after Jan. 2020. Plone 6 will be out long after Python 2 will be out of security fixes.

Proposal & Implementation

Officially drop Python 2 support for Plone 6 and cut Python 3 only branches for Plone 6.

Deliverables

• Do not set up Jenkins jobs for Python 2 for Plone 6
• Cut branches on all individual packages that drop Python 3 support

Risks

Branching too early might lead to the overhead of backporting lots of fixes. We shouldn't do this too early.

Participants

Timo Stollenwerk

[tisto]

@plone/framework-team please discuss and review.

@pbauer wanna second? :)

[ale-rt]

IMHO this is so obvious that should not even be a PLIP :)
Probably also 3.8 should be supported by Plone 6.

[sneridagh]

Cleaning all the branching and the six workarounds will be hard, and should be done. Having it as a PLIP is important for not overlook it, I think.

[jensens]

Communication wise it is good to have a PLIP, even if its the next obvious thing.

[ebrehault]

The FWT approved this PLIP

[fredvd]

As the possible risks list: actively removing Python 2 compatibility means creating a new major release of every subpackage Plone depends on first and blocking any sharing of stable not often changing package versions between Plone 5.2 and Plone 6.

This will negatively impact the support window for Plone 5.2 by increasing the workload for the release team to support the previous Plone version (backports).

Is this really such a necessity with huge benefits that it has to be forced/policied on Plone 6 and can’t wait until Plone 7 ?

[Juronski]

Would like to point to efforts for making Plone run on Tauthon (2.8.1). Tauthon is a Python 2.7 fork.
https://github.com/naftaliharris/tauthon/issues/129 and https://community.plone.org/t/plone-bug-report-from-santa/11180

[tisto]

@fredvd I see that risk too. We shouldn't branch packages too early or for no good reason. This PLIP is about officially dropping Python 2 support with Plone 6. This does not mean we have to start cleaning up right away. We could even postpone the cleanup until Plone 7. Though, we should be very clear that running Plone 6 on Python 2 is not supported in any way. I wrote this PLIP to lift off work from the core developers, the release team, the framework team, etc.

[Juronski]

I wrote this PLIP to lift off work from the core developers, the release team, the framework team, etc.

That is why I point to Tauthon. The migration to Python 3 provides us with unwanted work without added value. Plone 6 can support 2.7. With the future__ module Py 2.7 can act as 3. For lifting off work Plone only need to migrate to Tauthon. That is done once. In a couple of years Python 3 is going to be EoL'ed. Than again we get the unwanted migration work. So maybe the PLIP should go about migrating to Tauthon to lift off work from the core developers, the release team, the framework team, admins etc.

[tisto]

@Juronski This PLIP has been submitted to the Plone Framework Team and accepted. Therefore this PLIP will become part of Plone 6 and I have no intention of changing it. Please stop adding comments about Tauthon and keep the discussion in the community forum where it originated.

[Juronski]

@tisto sorry if this is not the right forum but I do not see that this PLIP has been accepted. I see it is a PLIP and that it is open for discussion in this forum. The PLIP is about lifting off work. What I read, learn and experience from Python 3 is that there is no security ore technical reasons to EOL Py 2.7. Python 3 does not lift off work. Python 3 does not make things more simple. Py 2.7 does. Everything can be done on Py 2.7. Python decide and we have to work our ass of to be able to maintain our Plone sites. The EOL of Python 2.7 is at the expenses of users without adding value. It has a negative effect on our growth. It is not normal to accept that from a supplier. I asked the Python Community to undo the EOL of Python 2.7. All I get is insults and hostility from there sysadmin in there PHP-forum. I do not want this needless migration work again when Python 3 is EOL’ed. If this is not the right forum, what is?

[CAM-Gerlach]

Cleaning all the branching and the six workarounds will be hard, and should be done.

@sneridagh It can't necessarily clean up explicit branches that test for Py 2.7 (though that's probably the easiest part to do manually), but PyUpgrade can automatically modernize most compatibility and legacy code, including replacing the great majority of six objects with their Python 3 equivalents. Sounds like this is what Zope is using as well, in zopefoundation/zope#724 to do the same thing.

[CAM-Gerlach]

FYI, users with write access on this repo can use Github's hide off-topic comments feature to hide this comment and the one(s) above it, if desired.

Disclaimer: I'm not a member of the Plone, Zope or CPython core teams and don't speak for them.

I do not see that this PLIP has been accepted

@Juronski See two comments before yours and the project assignment.

What I read, learn and experience from Python 3 is that there is no security ore technical reasons to EOL Py 2.7. [...] It has a negative effect on our growth.

Having been a maintainer, core developer and contributor to a range of Python projects, open source and otherwise, from a major Python scientific IDE (Spyder) to small personal scripts (including a few contributions to CPython itself), I originally began with Python 2, transitioned to Python 3 for my own projects and Py2/Py3 cross-compatible libraries and applications for open-source development, and now am exclusively Python 3 except for Python 2 porting work. Based on that experience, I personally would categorically disagree with the entirety of the quoted passage, and I'd imagine the Plone, Zope and CPython dev teams feel similarly given their respective decisions to drop support for Python 2, which is entirely within their rights as the maintainers of the respective software in question. Minus a an explicit contractual agreement to the contrary, you cannot simply force them to continue supporting legacy versions of their own _libre_ and _gratis_ software.

That said, you equally have the right to your own opinion about Python 2 vs 3, and as the projects involved are all open source, you are free to make your own choices. Software rot is just an unfortunate fact of life for any developer, whether its for a website, plugin, application, framework, or programming language. Any long-term software project, whether its Python, Zope, Plone or your own is ultimately faced with one of three choices: either port/modernize its code and clean house, deal with an ever-increasing amount of technical debt, or simply die. The aforementioned three have already all made the first choice for themselves, but thanks to open source you are free to make your own. You can continue using them as long as you wish (at your own risk, of course), fork them and maintain them yourself, pay someone to do so, or port your code to a modern version. Just like anyone is free to make their own choices for their software, you are free to pick any of the options for yours. That, after all, is the fundamental principle of free software: freedom.

It is not normal to accept that from a supplier

Neither is it normal (at least not in this century) that people demand that others do their work for them for free, yet here we are. Unless you have an explicit, written contractual agreement with both the CPython core team and that of Plone and have paid them for the privilege, there is no established business relationship that would create any such obligation as you imply. Like almost every other open source license (which you are bound by as a condition of using said software) Python's (PSF), Zope's (Zope) and Plone's (GPLv2) explicitly in ALL CAPS type disclaim any warranty or liability for the software, and provide it on an "AS-IS" basis only.

I asked the Python Community to undo the EOL of Python 2.7.

You asked on a community _forum_ intended for help, support and casual discussion, and whose members were in no position to do anything about it, mere weeks before an EoL a decade in the making, to undo a decision already published and executed out over 8 years ago. I hope you can understand why you weren't taken very seriously.

I do not want this needless migration work again when Python 3 is EOL’ed.

The core CPython devs have made it clear that any future Python 4, if and when it appears, will contain far less in the way of backward-incompatible changes relative to Python 3, both as a result of learning from the acknowledged pitfalls of the Python 2->3 transition and as a direct consequence of being relatively aggressive at cleaning out so much cruft during the same.

[tisto]

@Juronski I am a member of the Plone Framework Team. Eric Brehault, who is also a member posted on April 2th that the PLIP has been accepted:

https://github.com/plone/Products.CMFPlone/issues/2812#issuecomment-478987271

You can also read this in the notes of the FWT meetings. This is official.

This was a PLIP that took us 2 seconds to vote for. Some FWT members had the opinion that this is something we shouldn't even vote on because it is so obvious that we are not going to make a release that supports a Python version that reached its EOL.

As said before, please stick to the community forum to continue this discussion. If you continue to post on a closed PLIP with unrelated comments about this particular issue, we will have to think about taking measures to prevent this from happening.

[Juronski]

we will have to think about taking measures to prevent this from happening.

@tisto do't talk to me that way. You should have taken measures to prevent the EOL of Python 2.7 from happening.

[Juronski]

@tisto to make things more clear: I was in the impression that this PLIP was open for discussion. That this PLIP is accepted does not mean that my comments are out of place. On the contrary. The PLIP is about lifting off work. The discussion in this forum is about how to achieve this and about the time frame. It is about the execution of the PLIP. Is’t it?

My point is that the discussed execution will not fulfill the accepted PLIP. It shall provide Plone with more needless migration work in the future. The PLIP assume that Py 2 will not be supported after Jan. 2020. My proposal to make this PLIP really work is to invest in the certification/compatibility of a Py 2.7 supplier that fulfill the needs of Plone. I think this is the right forum to address this because this is the place where the members of the Plone Framework Team have there discussion about the execution of the accepted PLIP to lift off work from the core developers, the release team, the framework team, admins etc.

[CAM-Gerlach]

@Juronski The title of the PLIP is "Drop Python 2 Support for Plone 6". @tisto stated the Plone team overwhelmingly and unanimously agreed with and approved it as stated. Instead of demanding that other open source developers make a different decision for their own software to benefit your personal business interests, based on your opinion of Python 3 that they clearly don't share, consider spending the time, effort and passion toward either porting your sites/plugins to modern versions, or assembling the personnel, money, infrastructure and other resources necessary to support old versions of Plone, Zope, Python and their entire dependency stack indefinitely.

If you continue to post on a closed PLIP with unrelated comments about this particular issue, we will have to think about taking measures to prevent this from happening.

@tisto Just in case you missed it before,

FYI, users with write access on this repo can use Github's hide off-topic comments feature to hide my lengthy comment as well as other off topic ones; this doesn't remove them completely but rather collapses them by default and labels them as off-topic, so they don't derail the issue.

[ale-rt]

Oh wow :)
Nice discussion, but I am pretty sure the @plone/framework-team tean is compact in the decision of going on with this PLIP.
We will have shortly a new meeting next week and we can talk about this anyway.

In the meanwhile, I would suggest @Juronski to move the discussion elsewhere (maybe in a new PLIP?) exposing in a well organized and objective way the pros and cons and of maintaining Py2 support.

Every pro Py2 comment here feels like an obstacle to the flow of things that are "naturally" happening, rather than a proposal to make new things happen.

[Juronski]

@ale-rt I am happy to PLIP.

[jensens]

FYI I minimized most the comments as off-topic so far. Opening an own PLIP for discussion or using the community forum for pre-discussion is the right path.