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:
- Zope 4 no longer depends on sourcecodegen which was one of Zope’s dependencies Earl Zope II had to leave behind for the Python 3 wonderland.
- RestrictedPython can be used in AccessControl and already runs with legacy Python there.
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/testinstead ofpython setup.py testto run the tests as the latter one is no longer liked by the Python Packaging Authority folks.
I would suggest using tox instead of bin/test or setup.py test. That way you don’t have to debug the inevitable zc.buildout problems and testing different Python versions is easier.
Most of zopefoundation packages have a tox.ini. I’m adding those for packages that don’t have it as I encounter them.
There is an attempt of Tres to relate buildout.cfg and tox.ini a bit more, see https://github.com/zopefoundation/DateTime/pull/7
As one of the maintainers of jenkins.plone.org, we could do, just like we do with Plone, an integration so that any change on any Zope package triggers a jenkins job that runs all the tests. Would that be something you are interested in?
First of all though, we should have a working “buildout.coredev” for Zope, i.e. a repository with all the mr.developer sources and checkouts that can be used to assemble all the packages and create the test runner.
This could be interesting. There is https://github.com/zopefoundation/zopetoolkit and Zope itself also defines its dependencies as mr.developer sources: https://github.com/zopefoundation/Zope. The only thing which has to be done there is to set `auto-checkout` to `true`.
Like this: https://github.com/zopefoundation/Zope/blob/master/buildout.cfg ? 😉