Pre-discussion on PLIP - maintain Py2 support

Development
1

Hi forum,

Before I submit the below new PLIP to make PLIP #2812 really work and to make new things happen in a natural manner, I want to fish with this pre-discussion for constructive comments on this new PLIP and for seconders to support this new PLIP.

PLIP (Plone Improvement Proposal)

The EOL of Python 2.7 leads to migration issues and work overload. Unsolicited work needs to be done. Furthermore this work is experienced as needless. Without value being added. This PLIP proposes maintaining of Py2 support. This PLIP has been announced in the comments at PLIP #2812. The goal of PLIP #2812 is to lift off work from the core developers, the release team, the framework team, admins, etc. The goal of this new PLIP is to make the goal of PLIP #2812 really happen. And to make new things happen. In a natural manner.

Responsible Persons

Proposer: Juronski

Seconder: ……….

Abstract

Maintain Py2 support and invest in a new Py2 supplier.

Motivation

The motivation of this PLIP has to do with the EOL of Python 2.7. The PEP that EOL'ed Python 2 is experienced as an obstacle to the flow of things that are naturally happening, rather than that it make (new) things happen.

Plone Legacy and its third party products is a rich codebase suitable for almost all everyday business on the web. The EOL of Python 2.7 makes this unusable for online production buildouts. It can not be advised anymore because there are no Py2 security updates available from April 2020 onwards.

Migration to Python 3 is not an easy task and at the expense of resources, causing an obstacle for further and extended use and development of buildouts. Advanced Enterprise Plone Legacy buildouts can be created and maintained by admins without skills (so to speak). Migration to Python 3 is work for codemonkeys and Python Ninja’s. Python 2.7 is secure, there are no known security issues. It is dynamic and modular. It is state of the art. Almost perfect. With the __future__module Python 3 features can be backported to Py 2.

The print function in Python 3 is presented as the key difference between Python 2 and Python 3. Python 2’s print statement has been replaced by the print() function. Exactly this fact gives the impression that Python 3 is not needed because with the __future__module print can also be a function in Py2. That makes Py2 more easy than Python 3. Furthermore Python 3 has only one intuitive way of doing things as compared to Python 2. This makes Python 3 less flexible than Py2.

According to the discussion at PLIP #2812 even Plone 6 runs on Py2. In preparation of this new PLIP the question has been asked what Plone really needs from Python 3 that Python 2 can not provide. There came no answer. So it seems self evident to maintain Py2 support and invest in a new Py2 supplier to lift off work from the core developers, the release team, the framework team, admins, etc. And to make new things happen. In a natural manner.

Assumptions

Assumptions are that:

  • Py 2 can provide by way of __future__module and/ore other (new) modules ore way in the todays and future needs of Plone;

  • Py2 can do almost all the really neat things that Python 3 can do even when it doesn’t have it yet;

  • The new Py2 supplier delivers quality Py2 with security updates;

  • Investing in a new Py2 supplier is less work than all the migration work done by all Plone users on all there sites, every time a Python version is EOL’ed;

  • Plone Legacy has a rich egg supply on PyPy;

  • Almost all issue’s users experience with Plone Legacy have been answered by the Plone Community in the Plone Fora;

  • Maintaining an up to date Py2 fork is less work than migrating to Python 3 and every other Python version next by all Plone users on all Plone sites;

  • Plone want to strengthen its position in the market.

Proposal & Implementation

The proposal is: maintain Py2 support and invest in a new Py2 supplier.

The implementation of the first part of this proposal is easy. Everybody knows Py2. Py2 is well established. Till today Plone relies on Py2. Even version 6 runs on Py2. Maintaining Py2 support is continuing todays work without interruption. Nobody need to read about Python 3 migration efforts and learn its methodology for Python migration.

The implementation of the second part of this PLIP can also be easy. It can also be more complex. The second part of this PLIP can be implemented by contracting a new Py2 supplier. This supplier can be certified by Plone. The supplier can be selected by issuing a tender.

There is a Py2 fork active on GITHUB. Plone 4.3.19 can be installed on this fork with some changes in the versions. Documents et cetera can not be added in to a Plone site yet when this fork is used. This seemingly has to do with RestrictedPython. The feasibility of this part of the PLIP depends on the quality and compatibility (with RestrictedPython ) of the new Py2 supplier.

Optional Plone can maintain its own Py2-fork to lift off work from the core developers, the release team, the framework team, admins etc. Python 2 is FOSS. PlonePy, Plonethon ore Plython 2 can be a backwards-compatible fork of the Python 2.7.18 interpreter (expected April 2020) with new syntax, builtins, and libraries backported from Python 3.x. This way python code and C-extensions targeting Python 2.7 and below can run unmodified on the new Plone owned Py2-fork and produce the same output. This way Plone can also use new features from Python 3.x.

Forking Python 2.7.18 in to a Plone owned Py2-git is easy. Plone is compatible with this fork out of the box. The main work on this fork is (for the time being) to keep the security up to date. In terms of development work ‘only’ new things Plone want in its Py2-fork needs to be done.

Deliverables

Goods and/or services produced as a result of this PLIP are Plone Current and Plone Legacy with its rich ready to use egg supply on PyPy, and with the ability to use Python 3+ features, for everybody without the need to invest in migration to future Py-versions. This PLIP also can strengthen the position of Plone in the market as leading Enterprise CMS. The new Plone compatible Py2 supplier can make Python (TM) obsolete.

Risks

The risks of accepting this PLIP are:

  • the same risks as the use of Python 2.7;

  • the risk of increased workload on sales, services, after sales and accountancy’;

  • the risk of loosing track on future development by Python(TM);

  • the risks that comes with every Py 2 supplier.

The risk of not accepting this PLIP are:

  • that Plone is going to have a rich and growing legacy codebase with huge economical potential that is not being utilized, every time again when Python(TM) EOL’s a Python version;

  • that all Plone users need to invest in migration heavily every time a Python-version is being EOL'ed, without the experience of added value;

  • that users are going to get more unwanted and/ore unneeded migration work from there Py- supplier;

  • loss of market share ore lake of growth of market share ore an obstacle to get a bigger market share;

  • increased workload on developers, release teams, framework team, admins, and other Plone users.

  • the need of specialized admins and service providers to host and maintain Plone sites.

  • that Plone is in fact not FOSS because Python(TM) is in fact not FOSS because of imposed and unsolicited migration efforts at the expenses of resources, and its do or die methodology for migration.

Participants

All Plone users and everybody else with an interest in a Py2-fork with Python 3 features backported targeting Python 2.7 and below. According to recent reports 50% of the companies don’t have a plan for Python 2 EOL. So there is a demand and an attractive market for a new Py 2 supplier.

2

Again: Python 2 is dead, dead, dead for almost all of us. Everybody is on the move. And for the sites that won't be moved to Plone 5/Python 3, stick with the most recent Python 2.7 which may get security fixes from Redhat and perhaps someone will backport them to official Python 2.7 tree. The answer is basically: nobody cares anymore about Python 2. Python 3 is the future. Point. Deal with it (and don't annoy yet another community with your obscure ideas and demands. You got already the right answers e.g. from the Python community and the FreeBSD community). And again: everything is open-source. Fork everything what is needed...but do it yourself and maintain it yourself. The Plone community is not large enough for maintaining a future stack on Python 2 and Python 3. You're in a dead end and you know it. Upgrade your code. Python 3 is 11 years old. You really had enough time...

2 Likes
3
  • that Plone is going to have a rich and growing legacy codebase with huge economical potential that is not being utilized, every time again when Python(TM) EOL’s a Python version;

There is no incompatible Python 3 version on the horizon...invalid argument

  • that all Plone users need to invest in migration heavily every time a Python-version is being EOL'ed, without the experience of added value;

again: is this a one-time action after almost 20 years of Plone and Python 2

  • that users are going to get more unwanted and/ore unneeded migration work from there Py- supplier;

every system has a lifecycle and must be migrated of various reasons, in particular for compliance reasons

  • loss of market share ore lake of growth of market share ore an obstacle to get a bigger market share;

we can not maintain market share or gain market share with outdated technology that is basically up to 20 years old

  • increased workload on developers, release teams, framework team, admins, and other Plone users.

pure nonsense - the burden is to maintain old and outdated software. It is a burden for admins taking over legacy projects running on some old stacks without prospective being able to maintain them for the future.

  • the need of specialized admins and service providers to host and maintain Plone sites.

also nonsense. Administrating Plone is not always trivial. On the other hands there are approaches for making Plone pip-installable, running Plone on Docker etc.

  • that Plone is in fact not FOSS because Python(TM) is in fact not FOSS because of imposed and unsolicited migration efforts at the expenses of resources, and its do or die methodology for migration.

BS

4

I do not get the point.

  • The Plone Security Team still supports old versions with hotfixes and bugfixes as stated in the Plone update policy. Though, this does not include Python itself.
  • The Python Software Foundation stops supporting Python 2 April 2020. But if your enterprise depend on it, theres is professional support like by RHEL, see https://access.redhat.com/solutions/4455511 and others.
5

From a purely non-programmer, but sysadmin point of view:

  • this is not helpful. Yes, I have sites running on Python2.7 for the foreseeable future, as they depend on some add-ons not yet ported. Those will be just fine. There will be some security support from the major vendors. And otherwise, isolate those sites behind good firewalls. There's a vanishingly small chance that a catastrophic security issue will suddenly turn up, after all these years. Not likely, but hey things can happen. If that is the case, those sites will be made into static HTML. End of story.
  • all new sites are deployed on Python3
  • honestly, we have better things to do. Like a lot of better things. Like all the things.
  • there's windmills on the plains of Spain (mainly in the rain, if you want your My Fair Lady references :wink: ) if you want to fight losing battles.

in short, just don't.

4 Likes
6

I noticed that nobody answers the question what Plone needs from Python 3 that Python 2 can not provide. Python 2 is EOL’ed to make people pay for migration. At least I do not experience any added value from Python 3. It is experienced as a scam. This gone happen again when Python 3 is EOL'ed. Nobody answers the questions what problems Python 3 solves. Where do we need Python 3 for?

Do you people also rebuild your house from scratch when the DIY-store has new tools? It is total BS to say that Python 2 is outdated 20 years old technology. Python 3 is at the same level of technology as Python 2 because of the __future__module. The difference is dialectical.

7

Speed for example, lots of it.
Code sanity, lots of it.

1 Like
8

Your ongoing discussion is pointless and just wastes our time. The decisions have been made years ago. Live with it or die with your cruft. Take the Python 2 support in your own hands and leave us alone. If you want to jump from the cliff, jump now. If you are incapable dealing with your own legacy, then perhaps your legacy should be your tombstone. Even as a senior-senior-senior developer with a 5 before my age, I have all my stuff that is worth being supported running on Python 3...many of the projects already since 10 year. Stop crying, nobody will listen to you.

Apart from that: you never showed up in any of the Zope and Plone communities in recent year. Now after the EOL, you're getting panic and start noticing that you have a problem with your business. It's your legacy. You f*cked it up...you had time enough for bringing your issues up much earlier, not now. Go, go away...

9

text and bytes was the most significant and most important change

1 Like
10

The first Plone that supports Python 3 is published just recently. There has been no Plone supporting Python 3 before. All Plone supports Python 2 till Plone 5.2 just recently. So there is no way I could build my buildout on Python 3. There are almost no third party products for Plone 5.2 . Everything is there on Plone 4.3.

What has that to do with this subject?

I have not fucked up anything. I have a great buildout on Plone 4.3. It works perfect just as I want it. There never was a Plone based on Python 3 before till last month so I could not build my buildout on Python 3.

The EOL of Python 2.7 is fucking things up.

11

So Python 3 is more sane than Python 2? Python 2 was insane? Now Python 3 is sane?

And with respect to speed: the speed gain is marginal. Python 3.7 is only 1,19 faster than 2.7. And Python 3.7 it is the only Python 3.x that is faster then Python 2.7. Python 2.7 has been faster then Python 3 all the time till just recently. Conclusion: I have to invest in migration to get 19% more speed out of Python. I better buy a faster server and run Python 2.

12

That can not be imported in Python 2.7 by way of the ___ future ___ module?

13

In your proposal, who or what will make the investment and what resources will be invested?

1 Like
14

It's @jurons right to start a discussion and submit a Plip. I am against this Plip, but I am no longer in the Framework team which decides at the end. This is our Plone core development process, take it as it is, if you like it or not.

So @juron, you should convince the Framework team and the community over all. After all I don't see this is happening. It seems to me, your point of view of how release management, legacy support and community based development works differs giantly from the majority of Python, Zope and Plone community members. This is okay, but at some point you have to accept this, even if you disagree.
Then you still can collect alike minded people around you, fork away the 4.3 branch and work with them on it. It is GPL Code.

This said I am now off this discussion, because my time and energy is limited, and I am overall a person who tend to live in the present and look forward into the future. And even if the present still has a lot Python 2. 7 included, my future won't.

2 Likes
15

I think you are right. I also think the difference can be helpful to make things happen. My point of view is based on years of learning, use, administrating and maintaining FreeBSD/Linux/Zope/Plone/Python-2 sites. So in fact there can not be to much of a difference. Further more I think we all can have all the best of all worlds.

1 Like
16

This is nonsense. Most add-ons that work on Plone 5.0 and Plone 5.1 are usually (very) easy to port to Plone 5.2 and Python 3. There are various add-ons that worked on Plone 4.X but where never ported to Plone 5.0..that's the major issue. But this was the issue with all major upgrades of Plone. This is the same major issue with other systems when you do a major upgrade. Again: your crying and weeping is lame.

The major breaking change is that Archetypes will go away..again here: Dexerity is around since a decade and there was enough time moving away from Archetypes to Dexterity for years. Code running on Dexterity usually makes little issues under Python 3. Also Archetypes has been abandoned because we have something better - for ten years. And the cruft of Archetypes is so old and smelly that it does not makes sense for maintaining it with future release. Cruft has to go at some point.

You complain because you are either too lazy or unwilling for moving forward. And you expect others taking responsibility for your unwillingness and your own deficiencies regarding software and software management. In particular this comment below shows me that you have not understood how open source projects work...at least not this way. You're demanding from a Plone core dev member to fight against the Python 2.7 EOL...how absurd.

MacYET_2020-Jan-18
MacYET_2020-Jan-18954×490 136 KB

17

My point of view is that the dev-teams everywhere should have taken measures to prevent the EOL of Python 2.7 from happening. Especial those who sponsor Python (TM). Migration to Python 3 is a wast of time and resources. Furthermore I like Plone Legacy more than I like Plone Current. So I do not only have to migrate to Python 3. I also have to migrate to Plone versions I do not like to use. To survive I have to migrate to other distro's aswell. Honestly I am totally irritated by the EOL of Python 2. I very much dislike the attitude of the Python Community with respect to this. How much work is it for the big Python Community to keep Python 2.7 alive? And how helpful will that be for everybody else? Also the lack of good motivated objective arguments for the use of Python 3 gets on my nerves. What else is there to be expected from Python (TM) that makes me want to use PHP.

18

as said: there is basically no one here that cares about your desires. You're on your own and live wiit it.

The Plone core team dediced otherwise and also all Plone integrators and solution providers have the same opinion. The game is over. Deal with your situation.

19

I am dealing with the situation right now. The thing that maybe motivates me the most is that even @zopyx can not provide one convincing argument for the use of Python 3.

20

Be. My. Guest. I actually do administer PHP sites. Yes, PHP 7.x differs from PHP 5.x. Yes, I actually had to change code to keep it working on PHP7. So, you might wanna go to the PHP community and start your fight to keep PHP5 alive. Good luck, and cheers!

3 Likes