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.