One of my top priorities has been to port Mailman 3 (core) to Python 3. This work is now complete, and ready to be merged into trunk. No doubt bugs still lurk, but at least the entire test suite is passing. My intent is to merge this to trunk and do another beta release before the end of the year.
If you want to take a look at the branch, try this:
$ bzr branch lp:~barry/mailman/py3
The diff is available online via the merge proposal:
https://code.launchpad.net/~barry/mailman/py3/+merge/245313
It's a big diff.
$ bzr diff . --old ../3.0 | diffstat -s 166 files changed, 1881 insertions(+), 1538 deletions(-)
Python 3.4 will be the minimum required version. (It make work with earlier Python 3's but I will not officially support anything earlier.)
There are a few things to keep an eye out for, especially if you are currently experimenting with Mailman 3 in production:
A few database columns have changed from LargeBinary to Unicode. I have not yet figured out how to add the Alembic schema migrations to handle this, but I'll do so before the release.
The internal format of the requests table has changed. While the column type is a string, the internal format was a sort of home baked pickle-like format. This turned out to be incompatible with Python 3, due to some assumptions made about the format. I've changed this to using a JSON representation, which is safe and platform independent. This means that any held requests (subscriptions, unsubscriptions, held posts) must be cleared before switching to the Python 3 code. I don't think it's worth trying to migrate this internal format.
The new email API in Python 3 is really wonderful, but I am mostly not yet taking advantage of it. The one area that required a significant rewrite is in the Subject prefix munging code. Some Python 2 behavior is different in Python 3 and the old algorithms had to be rewritten. I've added a lot of tests, but there are probably bugs in the new code, especially when various mixed charsets appear in the Subject header.
Please do test, review, grouse, compliment, curse, rejoice, and enjoy. Over the holidays I'll spend some time cleaning a few things up (especially the documentation), then I'll merge this to trunk and do a 3.0b5 release as a Python 3-only application. Mailman 3 will not be bilingual so Python 2 support will be dropped.
Cheers, -Barry
One of my top priorities has been to port Mailman 3 (core) to Python 3. This work is now complete, and ready to be merged into trunk. No doubt bugs still lurk, but at least the entire test suite is passing.
Congrats !
- A few database columns have changed from LargeBinary to Unicode. I have
not yet figured out how to add the Alembic schema migrations to handle this, but I'll do so before the release.
This should be pretty easy, something like the following command should work: alembic -c src/mailman/config/alembic.cfg revision --autogenerate -m "python3 port"
[...] then I'll merge this to trunk and do a 3.0b5 release as a
Python 3-only application. Mailman 3 will not be bilingual so Python 2 support will be dropped.
Wow. I am very surprised. So we went from "Python3 compatibility is not on the blocker list for Mailman 3.0" to "Mailman 3.0 will only work on Python 3". That's quite a change. This means I must now port HyperKitty and Kittystore to Python3, check that we don't use Py2-only libraries, etc. And mailman.client must be ported too, since it does import stuff from mailman for testing purposes. I think Postorious is safe, but that must be verified (I believe it imports the testing framework from mailman.client and thus must be ported too).
And I thought the 3.0 release was almost there. I must say this is rather discouraging.
Aurélien
Here's a crazy, probably stupid idea. I want to do one more release before the end of the year, probably tomorrow.
What if I do A/B releases for 3.0b5?
A would be current snapshot of trunk, i.e. MM3 running on Python 2.7.
B would be current snapshot of the py3 branch, i.e. MM3 running on Python 3.4.
I will hold of on the merge until 2015.
The advantage of this is that folks would get a chance to download the tarballs of their choice and give it a try. I'd encourage people to try the Python 3 (i.e. B) release.
I think people are more engaged with an actual release tarball than with bzr branches, so this could provide some good feedback. I think right now the two branches are functionally equivalent.
Cheers, -Barry
Barry Warsaw writes:
What if I do A/B releases for 3.0b5?
Up to you; I have no objection.
But I'm only going to be looking at the Python 3 branch. I've already ported my (work internal) Django site to Python 3 (which was mostly trivial, I had more trouble with the Django upgrade itself).
participants (4)
-
Aurelien Bompard -
Barry Warsaw -
Barry Warsaw -
Stephen J. Turnbull