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.
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 gocept team will join PyConWeb 2017 in Munich from 27th to 28th of May – hey, this is is less than one week from now! It seems that there are still tickets available.
I myself will present RestrictedPython – or how to port to Python 3 without porting dependencies on Saturday at 3 p. m.
See you in Munich!
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!
Welcome to the Zope 2 Resurrection Sprint in Halle (Saale), Germany. We hope you enjoyed the time since the Last call for take off to the Python 3 wonderland.
We already achieved some things:
We discussed the following topics:
- Use pytest as test framework and test runner for the Zope projects?
- We decided against this suggestion as it is to much hassle for a too little gain.
- Using zope.testrunner is not too different from stdlib’s unittest.
- zope.testrunner it has the really helpful layers feature which is heavily used in Zope and especially Plone. There is no equivalent in pytest for this concept. This would require to rewrite the whole test infrastructure or use a tool like gocept.pytestlayer which coverts layers into purest fixtures – but has its own problems doing this.
- Improve the situation of continuous integration for the Zope packages:
- Sometimes tests of a package break because a dependency has changed its behaviour. This does not get noticed until someone makes a change to the package which triggers Travis-CI. It is sometimes really hard to find out which change in which package caused the test failures when the tests are only run at code changes. (Current example: zope.testbrowser which broke because of a change in WebTest.)
- Hanno activated the cron jobs Travis-CI beta feature for most of the Zope related packages. (This currently requires clicking in the Travis-CI UI and still has to be done for most of the ZTK packages.) Currently it is not clear what happens if such a cron job fails.
- The Jenkins of the Plone Foundation is also able to test the Zope packages: it could be configured to run them on a regular basis.
- Tres suggests to use
bin/test instead of
python setup.py test to run the tests as the latter one is no longer liked by the Python Packaging Authority folks.