Earl Zope is now nearly settled down in Python 3 wonderland. On the Zope and Plone sprint from Monday, 1st until Friday, 5th of October 2018 in Halle (Saale), Germany we will work towards the final Zope 4 release aka the final permission for the Python 3 wonderland.
We are currently 33 participants for the sprint. So be prepared for a huge sprint with many interesting people. The Saltlabs have a café (called KOFFIJ) we can use, a big meeting room with big display (aka the Thronsaal) and many smaller rooms including the offices of gocept. So there will be enough room to work in bigger and smaller groups.
To keep the organisational overhead low with this amount of participants, we plan to separate in two teams: Zope and Plone. Those teams will organise themselves individually and we will have a short daily meeting after lunch to share the status in a condensed manner with the other team. Direct communication in case of a difficult problem is, of course, always possible.
We reserved up to one hour after the daily meeting for talks and presentations by you about interesting topics around Zope and Plone, successful migration stories, or something else you want to share with the community. So if you have some interesting slides, please bring them with you and register during the week for a slot.
Our current schedule:
- 19:00, there is a table reserved at Grober Gottlieb, so if you’ve already arrived and want some company, you are invited to join.
- 9:00 Breakfast at KOFFIJ (This is the café in the ground floor of Saltlabs aka the window to the left on the picture above.)
- 10:00 Welcome at KOFFIJ and start sprinting afterwards
- 12:30 Lunch
- 13:30 Sprint planning and introduction for all sprinters at Thronsaal
- between 15:00 and 17:00 coffee break at KOFFIJ
- 18:00 Lights out
- All other days:
- 8:30 Breakfast
- 9:00 Standup in the team (Zope, Plone)
- 12:30 Lunch
- 13:30 Daily meeting at Thronsaal
- 14:00 (Lightning) Talks at Thronsaal
- between 15:00 and 17:00 coffee break at KOFFIJ
- 18:00 Lights out
- 11:00 till 17:00 Massages, there will be a list to register on Monday
- 19:00 social evening at Eigenbaukombinat (local hacker space) with pizza, beer and mate
- 13:30 Closing meeting with presentations at Thronsaal
- 17:00 Lights out
If you cannot make it to the Welcome meeting, ask at KOFFIJ for one of the gocept staff to get a personal introduction.
Parking: As Saltlabs in located in a pedestrian zone, the availability of parking spots is rather low. Please use one of the parking decks nearby.
As organizational tool to coordinate the work, we try to use Github projects this time, as it allows cross-repository tracking of issues.
One last hint: The location of the sprint is Leipziger Str. 70, Halle (Saale), Germany.
TL;DR Use zodbupdate.
Data.fs which was created under Python 2 cannot be opened under Python 3. This is prevented by using a different magic code in the first bytes of the file. This is done on purpose because
str has a different meaning for the two Python versions: Under Python 2 a
str is a container for characters with an arbitrary encoding (aka
bytes). Python 3 knows
str as a text datatype which was called
unicode in Python 2. Trying to load a
str object in Python 3 which actually contains binary data will fail. It has to be
bytes is an alias for
str in Python 2 which means Python 2 replaces
str making is impossible to give Python 3 the class it expects for binary data. A Python 2
str with an arbitrary encoding will break, too.
Data.fs has to be migrated: each
str which actually contains
bytes has to be converted into a
zodbpickle.binary object which deserialises as
bytes under Python 3. The
str objects actually containing text have to be decoded to
unicode. There are currently two tools which claim that they are able to do such a migration:
- zodb.py3migrate was already written at Berlin Strategic sprint in 2016, but it was never able to prove that it can do what it claims: At the time when it was written there was no Zope which could run on Python 3. Now as we have Zope 4 running on Python 3 it does not seem to do its conversion job quite well: I was able to migrate a toy database but had to catch an unpickling error.
- zodbupdate was enriched by a Python 3 migration. A big thank you to Sylvain Viollon and the developers at Minddistrict! It has proven its claims! At the Zope 4 welcome sprint I was able to migrate a
Data.fs created on
Zope 2.13 running on Python 2 to
Zope 4 running on Python 3.
- Migrate your Zope application to
Zope 4. (
zodbupdate requires at least
ZODB 4 which is not the default ZODB version of
Zope 2.13) — For my toy database containing only a file object and an image this was no problem.
Zope 4 is starting with such a database. It might show some broken objects because Zope no longer depends on some previous core packages like
Products.Sessions. If your application needs those packages you should add them to your Zope environment.
zodbupdate has to be installed into the
Zope 4 environment so it can access the Python classes. (It has to read the pickles in the ZODB.)
- There needs to be an
setup.py for each package which contains persistent Python classes. The entry point has to be named
"zodbupdate.decode" and needs to point to a dictionary mapping paths to
str attributes to a conversion (
bytes resp. a specific encoding). For Details see the migration documentation of zodbupdate. I prepared a branch of
Zope 4 which contains this configuration dictionary for
OFS.File, see zopefoundation/Zope#285.
zodbupdate --pack --convert-py3 on the
Data.fs using Python 2.
- Copy the
Data.fs over to the
Zope 4 instance running on Python 3.
Data.fs.index will be discarded at the first start. (There is an error message telling that it cannot be read.)
- Enjoy the contents of the
Data.fs running on Python 3.
It is possible (proven for a toy database) to migrate a
Zope 2.13 (Python 2) to
Zope 4 (Python 3).
zodbupdate is the way to go. Although it cannot do the migration completely autonomously the developers of Python packages can provide migration configuration in their packages which can be used in the migration step so the configuration has only to be written once.
zodb.py3migrate has an analysis step which shows the attribute names where the
str objects are stored. (This could be added to
zodbupdate, so do not expect that there will be two tools trying to achieve the same goal.)
mdtools.relstorage contains a
relstorage variant of
zodbupdate which claims to be much faster on
relstorage as it can leverage parallelism.
The pull request containing the migration strategy (zopefoundation/Zope#285) has to be extended for the other persistent classes in Zope. There have to be alike changes in all packages providing persistent classes.
Beta-Testing Zope 4 together with PerFact Innovation
TL;DR: There are some rough edges when migrating an existing Data.fs and needed Python code from Zope 2.13 to Zope 4 but there is nothing what cannot be solved.
The German company PerFact Innovation (www.perfact-innovation.de) has a customer product built on Zope 2.13. The code needed for the customisation to different customers is stored in the ZODB. They invited me to a workshop where we looked into the migration story to Zope 4. We used the just released Zope 4.0b2.
After half a day the core functions of the customer product where working including the switch from ZServer to WSGI. There were some rough edges we had to come around. I list them here as a reference for other people who start migrating their code to Zope 4.
We also poke around with a fresh Zope 4 installation on Python 3 to see what this will bring. It was nice to see that a
DTMLMethod calling another one while mixing
unicode no longer leads to strange encoding problems but keeps
Expect most of the bugs and some of the uglinesses listed below to be fixed in Zope 4.0b3.
There are some bugs we could easily hack around in the workshop. Most of them are even fixed by now:
- Some objects cannot be loaded from the ZODB because their classes used to be old-style classes but in Zope 4.0b2 they became new-style classes. Fixed in [zopefoundation/Zope#205]
- Python scripts cannot be called because the compiled code is expected on a different attribute. This requires re-compiling them. Fixed in [zopefoundation/Products.PythonScripts#12]
- Some modules seem no longer allowed to be used in through the web PageTemplates, e. g. Products.PythonScripts.standard. Fixed in [zopefoundation/Zope#209]
- Accessing METAL macros using the
getitem style (e. g. metal:use-macro=“python:here.master.macros[‘foo’]“) is not allowed. Its Python class seems to be missing a security declaration. Reported in [zopefoundation/Zope#210]
- When using Python 3 it is not possible to create a new
Script (Python) in the ZMI because the default script code is not Python 3 compatible. Already fixed in [zopefoundation/Products.PythonScripts#10] awaiting release.
Some things are still a bit raw in Zope 4 but for a beta version it is possible to live with them:
We were facing some of the breaking changes in Zope 4, which will require further development if the customer product should behave and be developed like before:
- Support for WebDAV, XML-RPC and FTP has been moved to the ZServer package. This means a WSGI based installation does not provide support for these protocols. Maybe WSGI middlewares could be written to support them again individually.
products directive is no longer supported in the
zope.conf (only via ZServer). This means that the contents of the
Products directory inside the Zope instance directory have to become Python packages which can be installed via
We were facing some required changes on different levels to get the code running:
- Installation: Some Python packages are no longer dependencies of Zope or they have been extracted to separate packages and Zope does not depend on them. They have to be installed separately when they are needed. These packages are:
- Products code: Zope 4 no longer contains the
Globals module. In Zope 2.13 it only contained imports to keep the backwards compatibility with older Zope releases.
Globals is gone now. To find out how to change your imports look at the Globals module on the 2.13 branch.
- PageTemplates: PageTemplates are now rendered using Chameleon. This prevents you from using
-- in HTML comments as it is not allowed there. (See also the HTML comments document of the WebDesignGroup.)
- Error handling:
standard_error_message does not exist any more in Zope 4. It only supports exception views which have to be written in file system code. See Catching and rendering exceptions as a tutorial how to create exception views and even a hack to restore using
It is not impossible to migrate an existing Data.fs to Zope 4 (while staying on Python 2). It is even easier if the through the web approach was used to create the Data.fs as only very little code has to be modified that way.
Please test your applications on Zope 4 during the beta phase (until fall 2018) so we will get a final release which will be ready for production usage. If you have questions we are here to help.
Once upon the time there was Earl Zope II. His lands where threatened by a huge disaster called “Python 2 sunset”. His only chance was to emigrate to the Python 3 wonderland. After a long preparation phase for himself and his courtiers he was able to move to the new land. But the Python 3 wonderland has strict immigration authorities: They only allow “compatible” fellows to get a residency permit. The permission itself has three levels:
- alpha – To get this level the candidate has to prove that he can breath the Python 3 air and drink the water in this land without getting falling over. Earl Zope II needed a while to acclimate in the Python 3 wonderland as its climate is a bit different from what he was used to.
- beta – This level requires the the acclimation phase was successful and people could start to rely that the candidate will stay in the new land. Earl Zope II reached this level by proving that all his courtiers – he relies on – are ready for this level.
- final – To reach this level the candidate needs to prove that he is living in successful relations in Python 3 wonderland. Other inhabitants must be able to trust him and the services he offers. After Earl Zope II now has reached the beta phase he is now able to offer his services and hope that he gets the final level about fall 2018.
Back in his own country Earl Zope II had the official name “Zope2 2.13”. Before the beta phase of his immigration he thought that he would have to change the name to something like “Zope2 4.0b1”. This is looks ugly and some people protested against this name. With the kind and quick help of Baiju Muthukadan Earl Zope II was able to change his official name to “Zope 4.0b1”. Thank you very much Baiju Muthukadan! Earl Zope is very proud of this new shorter name and is heartily thankful for this opportunity.
The release of the first Beta version means, that no currently existing features will be removed until the final version. But There will be some new features and many bugfixes.
New Features of Zope version 4.0
- Support for Python 3.4 up to 3.6: Currently Python 3 can only be used for new projects. There is only an experimental way to convert an existing ZODB from Python 2 to 3 as it is not possible to run the same
Data.fs under both versions, see zodb.py3migrate.
- Zope now by default runs as a WSGI application. The previously used
ZServer is still supported but only runs under Python 2.
- Chameleon based templates are now the default.
- The name of the distribution changed from
Zope. The previous
Zope2 package will remain as a meta package which depends on
Zope. This allows packages which require Zope 4.x to depend on
Zope instead of
- Removed deprecated code and BBB imports like the
Globals package or the internal help system.
- Some smaller features, bug fixes and security fixes, see the Change log.
A big “Thank you!” to all who made this release possible:
- dedicated people investing time, thoughts and money
- nice companies allowing their people to participate on Zope sprints
- the Plone Foundation sponsoring Zope sprints
We had a great Zope 4 Phoenix Sprint helping to raise Zope from the ashes! Thank you to everybody who participated in Halle or from remote.
Beta one of Zope is out:
We need the feedback to adapt Zope to the needs in the wild. The current plan is to create new beta releases once a while after implementing features resp. bug fixes or on demand. The current plan is to release a final 4.0 version in fall of 2018. This should allow software projects built upon Zope to migrate there code before the Python 2 sunset in 2020.
Once upon the time there was an earl named Zope II. His prophets told him that around the year 2020 suddenly his peaceful country will be devastated: They proclaim that with the “sunset” of Python 2 as stable pillar of his country, insecurity and pain will invade his borders and hurt everyone living within. There seemed only one possible move forward to escape the disaster: Flee to the Python 3 wonderland, the source of peace and prosperity.
This was not as easy as one might think. Earl Zope II was already an old man. He was in the stable age where changes are no longer easy to achieve and he had many courtiers in his staff which he needed all the day.
The immigration authority of the Python 3 wonderland was very picky about the persons which requested permission to settle down. Many “updates” for Zope II and his staff where required to so they eventually became “compatible” with the new country. Earl Zope II was even forced to change his name to Zope IV to show hat he was ready for Python 3 wonderland.
After much work with the immigration authorities it seemed to be possible for earl Zope IV to enter; only some – but important – formalities were needed before he could be allowed to settle down and call himself a citizen of the Python 3 wonderland.
This is where the tale gets real: We need your help to release a beta version of Zope 4. The hard work seems to be done; but some polish and testing is still required to reach this goal.
We invite you to the Zope 4 Phoenix Sprint to help raising Zope 4 from the ashes! From Wednesday, 13th until Friday, 15th of September 2017 we sprint at the gocept office in Halle (Saale), Germany towards the beta release.
Possible sprint topics could be:
- Work on issues and pull requests regarding the beta release.
- Make RestrictedPython beta ready.
- Work on a Bootstrap of the Zope management interface (ZMI)
- Port CMF components to Python 3 to test Zope 4 for possible issues
- Work on Plone to make it ready for Zope 4
- Try out migration strategies for ZODB content to Python 3.
- Improve the documentation.
You are heartily invited to join us for the honour of earl Zope IV.
Today we migrated the documentation of zodb.py3migrate from pythonhosted.org to zodbpy3migrate.readthedocs.io.
This requires a directory – for this example I name it redir – containing a file named index.html with the following content:
content="0; url=http://zodbpy3migrate.rtfd.io" />
Redirect to zodbpy3migrate.rtfd.io
To upload it to pythonhosted.org I called:
py27 setup.py upload_docs --upload-dir=redir
Now pythonhosted.org/zodb.py3migrate points to read the docs.
Credits: The HTML was taken from the Trello board of the avocado-framework.
UPDATE: The approach described here no longer works as the required API has been shut down. See pypa/warehouse#582.
The sprint days were really busy for Earl Zope II and the people helping him with the Python 3 wonderland immigration authorities.
- can be installed using Python 3
- can be started and renders some views
- has more than 1.700 of more than 2.300 tests running
- has some optional dependencies left to be ported.
- To accomplished this by:
- Complete porting of RestrictedPython, so a first alpha release with the new implementation was released. (This includes about 260 commits, nearly 100 files changed, 9.000 lines of newly written code and 1.000 lines of code deleted.)
- Port AccessControl to Python 3. This port covers the Python code of the package.
- Make an alpha release of DocumentTemplate which supports Python 3. It is purely based on Python code. (Thanks Hanno for the porting work from C to Python!)
- Note: There were problems porting AccessControl and DocumentTemplate to PyPy so we left this out for now. (Volunteers welcome!)
Besides working on Zope there was other ongoing work:
- CMFCore, DCWorkflow, GenericSetup now run on Zope 4 using Python 2.
- Even most tests of CMFDefault are now running on Zope 4 – whereas it runs successfully in the browser.
- Some Plone packages were ported to Python 3:
His majesty Earl Zope II says a warm “Thank you!” to all who helped him to start his new live in Python 3 wonderland. There is still enough work to be done so he can live there and having all the comfort and stability of Python 3. See you on the next sprint!