Earl Zope already got the beta permission to stay in the Python 3 wonderland some months ago. His current objective is to help old friends to come to the Python 3 wonderland and to make new friends. He has to build trust in his will and ability to stay in the Python 3 wonderland.
The Zope-4-Welcome sprint last week was a great opportunity to work towards the final permission for Earl Zope. We were a group of 15 developers from different companies and backgrounds building applications on Zope in various ways.
We accomplished the following goals:
- There are some old friends of Earl Zope. He thought that he no longer needs them in the Python 3 wonderland but other applications built on Zope need them, so they were pushed towards the new land:
- Knight RestrictedPython got some love and a new beta release.
- Earl Zope could help an old friend (a custom Zope 2.13 application) to get prepared to move to the new land.
- Duchess CMFCore got a beta permission for the Python 3 wonderland including her beloved siblings:
- Prince Plone is not yet ready to live in the Python 3 wonderland but he is already a welcome guest. It is only a matter of time before he will get an alpha permission:
- The instance starts and many actions in the UI work pretty well.
- The test story was brought some steps further so it is possible to start testing Plone under Python 3.
- Details are described in a Blog post of Philip Bauer.
- The migration of a toy
Data.fs was tested and successfully completed. (Details will follow in another blog post.) The Migration took the following steps:
- from Zope 2.13 on Python 2.7
- via Zope 4 on Python 2.7
- to Zope 4 on Python 3.6
- The ZMI of Earl Zope got a facelift (Zope#249) which is not complete yet but looks promising.
- And last but not least Earl Zope himself got the 5th extension of his beta permission: Zope 4.0b5.
Earl Zope says a hearty thank you to all who where involved in this sprint in Halle or remote by coding or providing the resources and time to code.
Welcome in the Python 3 wonderland!
Today we had the following error message when re-installing a project from scratch:
Getting section application.
Initializing section application.
Installing recipe zc.zope3recipes.
Getting distribution for 'zc.zope3recipes==0.13.0'.
Error: Couldn't find a distribution for 'zc.zope3recipes==0.13.0'.
Yes this is a really old recipe but it still exists on PyPI. We are using
zc.buildout in Version
2.10, and do not use a custom
index. So being forced to use HTTPS to access PyPI does not seem be the problem.
After searching way too long we found that
.buildout/default.cfg contains the following statement:
It restricts the allowed hosts for download but it seems to restrict the index, too.
https://pypi.python.org/simple nowadays redirects to
https://pypi.org/simple which is not on the list.
allow-hosts if possible. It is more harmful than good, especially because packages are nowadays downloaded from
I filed an issue for
zc.buildout at GitHub: buildout/buildout#447
Once upon the time there was Earl Zope II. A wise guy was telling him that his world will come to an end. He found out that this was true that he had only some years to prepare to immigrate to the Python 3 wonderland.
His preparation was successful: He got past the strict immigration check and has now a beta permission to stay in the Python 3 wonderland. Earl Zope really likes his new home, but he is missing some friends. Most of them are still at the border of Python 3 wonderland and have to go through the immigration process. Earl Zope would be pleased to offer the same service to his friends as in the old Python 2 land.
To get the final permission to stay in Python 3 wonderland Earl Zope needs to build up trust in his abilities and his stability by other inhabitants and old friends. Therefore, he has to show, that he can work with old and new friends in the Python 3 wonderland.
Zope 4 Welcome sprint – 16th until 18th May 2018
Earl Zope invites you to join a sprint with some helpful people to welcome Zope 4 and his friends in Python 3 wonderland. This means: Bring in your Zope 2 based application and we look together how to port it to Zope 4 or even Python 3. That’s why we call the sprint “Zope 4 Welcome sprint”. You can also help by posting issues or even pull requests about your migration attempts.
Additionally we look forward to work on an improved version of the ZMI (Zope Management Interface) and to fix some bugs preventing Earl Zope from getting the final permission.
The sprint will be located in Halle (Saale), Germany. We meet there from Wednesday, 16th till Friday, 18th of May 2018. Please join us via Meetup even if you are planning to work from remote. You will find more detailed and updated information about the sprint there, too.
If you cannot access the root level in Zope 2 via the browser but you are able to use the debug console you have enough to undo transactions.
Start the debug console:
$ bin/zinstance debug
List the transaction descriptions, user names and ids of the last 10 transactions:
>>> from pprint import pprint
>>> pprint(app._p_jar.db().undoInfo(0, 10))
(0 is the youngest transaction, the first one to show)
Undo some transactions:
>>> import transaction
>>> transaction.get().note(u"Undo transactions: ...")
>>> app._p_jar.db().undoMultiple([id1, id2])
(id1, id2 have to be the actual id strings from the transaction listing.)
- Use a sorted list of transaction ids, start with the id of the youngest transaction you want to undo.
- You cannot undo transactions those objects were changed again later without undoing those transactions, too.
- The actual undo is executed when calling
transaction.commit(). (This might take some time to execute.)
- You can check the result of your undo using the transaction log as undo only creates an inverse transaction.
This blog post first appeared on icemac15.wordpress.com.
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.
TL;DR: You have to write an exception view in file system code which is rendered when an exception occurs.
If an exception occurred in Zope 2 the
standard_error_message (an object in the ZODB) was rendered. This way the error page could be customised through the web.
When using a WSGI server on Zope 2 the
standard_error_message is no longer used. The exceptions have to be handled in a WSGI middleware. (This is a sub-optimal solution as the middleware is not run in the same execution context where the exception occurred.)
Thats why error handling changed again in Zope 4: Like Zope 3 (aka BlueBream) Zope 4 tries to lookup an exception view if an exception occurs. If the lookup succeeds (aka there is an exception view registered for the current exception) this view is rendered as response. This approach allows different views for different exceptions. The
standard_error_message is even gone when installing Zope 4 from scratch.
Continue reading “Catching and rendering exceptions”
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.