Faster tests and python 3

2x faster

Thanks to the Plone Foundation that is sponsoring a new dedicated server for our jenkins nodes (the machines that run our test suite on every change),
the Plone community is starting to enjoy faster builds (twice as fast!).

If your pull request or jenkins job runs on Node 5 or Node 6 you will notice it :-)

Please report any misbehavior on jenkins.plone.org github project if you happen to notice something not working as expected.

Happy testing!

Python 3

As the Zope community is getting closer and closer to make a Zope release Python 3 compatible, us, the Plone community have to step up and do the same.
For that, we are working on, guess what, a new Jenkins job that will only run the test suite of all packages that are known to work on Python 3 already.

The initial list isn’t that big, roughly 10 packages so far, but as more and more Zope packages are updated, the more Plone packages that can be made compatible as well.

The upcoming Alpine Sprint will be dedicated towards this: getting a Plone version compatible with the current Zope versions, which will eventually lead to this Zope on python 3 target (aimed to be released by the end of next year).

Happy hacking!

Plone on python 3 status

2020 is approaching fast, one day at a time, and besides being a nice catchy year, it will be also the year where Python 2.7 will no longer get any security updates.

What that means for Plone? We should hurry up and get a python 3 porting of the whole stack, yes, including Zope, ZTK, ZODB and all the tooling around (zc.buildout, etc etc).

Fortunately quite some tooling and Zope/ZTK/ZODB is already updated and there’s ongoing effort on porting the remaining parts.

The big elephant on the room blocking any porting effort of Plone to python 3 was RestrictedPython, a python distribution that, quoting itself: provides a restricted execution environment for Python.

Note the past on the previous sentence.

Since RestrictedPython is being worked, now it’s high time for the other python distributions from Plone to be also made compatible with Python 3. Stay tuned for the Plone Conference 2016 sprint report!

Copy&pasting&adapting a set of scripts to track the progress of the porting for the Zope foundation github organization, results here, I made the same but tracking what Plone 5.1 (including our testing environment) looks like on Python 3:

http://jenkins.plone.org/py3/

The code is on collective, so feel free to update the package list.

During the Plone Conference 2016 there is quite some work put on either reducing the amount of dependencies, or updating our stack to use newer (already python 3 compatible) part of the underlying stack.

The clock is ticking and Plonistas all over the world are working hard on it!

python 3 support one (of the many) step closer

During the Barcelona sprint (report from Paul and Ramon) there was quite some work to bring dexterity related packages to work both in python 2.7 and python 3.5.

That work is mostly still pending to be merged, because we had a blocker: our current CI infrastructure (namely jenkins master and its nodes) run on a version of Ubuntu ((14.04 for the curious)) that does not provide python 3.5 by default.

So it would be a bit irresponsible to merge those changes without a way to ensure that the effort that was put during that sprint is not long forgotten and had to be done again from scratch some months later.

As reports about the newer Ubuntu version regarding python and plone are not that encouraging, and also due to other reasons, I decided to take the longest but long-term best approach: enters gforcada.compile-python!

An ansible role

So I decided to create an ansible role, given that our jenkins CI setup is already using some, and Plone community is also favoring it, to install all the system dependencies to compile Python 2.6, 2.7 and 3.5.

As extras I added:

install virtualenv on python 2.6 and 2.7 (on python 3.5 is already available)
install system dependencies for Pillow and lxml

See its README for all the details and more.

With that and vagrant I was able to test that a buildout.coredev (branch 5.1) runs all its tests without a problem :-)

I was tempted to add pypy as well, but I was too lazy/busy for that, if anyone feels like it, pull requests are always welcome!

I hope you find it useful and happy hacking!