Make Trac work with Python 3

[Remy Blank]

With Genshi having been ported to Python 3, we could start thinking about how we can achieve the same with Trac. As a first step, we should check if our dependencies have a Python 3 port:

Database backends	SQLite	builtin sqlite3, PySqlite?
	PostgreSQL	​psycopg 2.4
	MySQL	​unofficial mysqldb or ​pymysql
Version control bindings	Subversion	unlikely (1)
	Mercurial	unlikely (2)
Web frontends	Apache	​mod_wsgi
Others	setuptools (​Distribute)	works (3)
	Genshi	​trunk starting with ​[G1162]
	Babel	#bl209
	​pytz	works (2011d)
	docutils	works (4)
	pygments	works (1.4)

Notes

• svn: not much activity on the bindings; rather go the svn.exe way
• hg: after 2 GSoC projects already, the efforts seem to have stalled
• distribute: seems ok on Linux, "works" more or less on Windows; might be worth to wait for ​distutils2
• docutils: seems it was ported and works on Linux, but easy_install docutils on Windows hangs… Installing docutils-0.7.tar.gz also hangs, so it seems it's not distribute's fault.

Once we have at least one backend, VC binding and frontend ready, the next step would be playing with 2to3 and see what comes out. See also resources listed in ​PortingPythonToPy3k.

Let's set the milestone tentatively to 0.14.

[Eli Carter]

There is also a 3to2 tool, and rumors here at PyCon that 3to2 will (soonish?) have the ability to take Python 3 code and output versions that will work for 2.7, 2.6, 2.5, and maybe even 2.4.

[Christian Boos]

Replying to ecarter:

There is also a 3to2 tool, and rumors here at PyCon that 3to2 will (soonish?) have the ability to take Python 3 code and output versions that will work for 2.7, 2.6, 2.5, and maybe even 2.4.

For projects that need to be migrating away from Python 3? ;-)

[Christian Boos]

Create a table for the packages and document some already py3k compatible packages or in-progress status.

[Christian Boos]

Correction: Simon Cross' py3k branch not yet on trunk apparently.

[Remy Blank]

Added some data according to what's installed on my machine (Gentoo Linux).

[Christian Boos]

Report my early experiments with distribute on Python 3.2 (x64) on Windows 7.

[Christian Boos]

Add some infos on db related packages. Nothing actually tested, though.

[osimons]

I think 3k support is a valid target for Trac 0.14, but as a note of warning I think the target should be to get 0.14 to run internally (passing tests) but NOT make it an announced and supported configuration until later.

There is hardly anyone running Trac without plugins, and getting 3k support in 0.14 helps establish the fixes, best-practices and compat code needed to help plugin developers get converted too.

If we push this out too soon admins will just end up being disappointed and end up reverting to 2.x just to get their configuration working. It is really a no-win situation to make this officially supported too soon.

[Felix Schwarz]

I'd like to add that ​pytz has an official Python 3 package (see ​tracking bug where I attached my patches).

For Babel Python 3 support is actually my no 1 item to release 1.0.

[Christian Boos]

Replying to fschwarz:

I'd like to add that ​pytz has an official Python 3 package

Ok, that was actually what got easy_install'ed when I tried. Thanks for the additional details!

[Thijs Triemstra]

Replying to osimons:

… but NOT make it an announced and supported configuration until later.

I agree but *some* mention of the support should be made so people can start looking into porting their plugins, even though knowing it 'isn't expected to work' right?

[Eli Carter]

Replying to cboos:

Replying to ecarter:

There is also a 3to2 tool, and rumors here at PyCon that 3to2 will (soonish?) have the ability to take Python 3 code and output versions that will work for 2.7, 2.6, 2.5, and maybe even 2.4.

For projects that need to be migrating away from Python 3? ;-)

Heh. :) No, the idea here is that the Trac source could be fully migrated to 3.0 and then support 2.x via a "compilation" step so we don't have to drop support for "conservative enterprise distros" as a side effect.

[Christian Boos]

Btw, Genshi trunk should now support py3k. Would be nice to verify the compatibility with our current trunk (and 0.12-stable as well) with it.

[Christian Boos]

The big question is: do we gain anything with this? And if yes, would it be worth the trouble?

[Remy Blank]

The answer is quite simple: at some point, we won't have a choice anymore. Guido has made it very clear that there will never be a 2.8, and that the upgrade path from 2.7 was 3.x. In a possibly distant future, 2.7 will be marked EOL, and many libraries will stop supporting 2.x. Then we will be stuck with old versions of our dependencies.

I still agree with an "unscheduled" milestone, though. I would rather wait for all dependencies to be migrated and stable on 3.x before even attempting anything.

[Christian Boos]

Well, Python is open source and it might well that other people at some point stand in and go the 2.8 way… Or rather, that some later 3.x becomes more 2.x migration friendly, as just happened recently with the reintroduction of support of u"" strings in 3.3 (​PEP:0414).

If one "porting" effort should be done, it could perhaps better be towards supporting PyPy, we'll probably have more to gain there performance-wise (hasn't someone started this, ISTR? was it Jun?).

[Jun Omae]

Replying to cboos:

If one "porting" effort should be done, it could perhaps better be towards supporting PyPy, we'll probably have more to gain there performance-wise (hasn't someone started this, ISTR? was it Jun?).

Yes, I've started on repos:jomae.hg:pypy-trunk with PyPy 1.6, SQLite and no version control backends.

setuptools, Babel, Genshi (without speedups), pytz and pygments work fine on PyPy. More information at ​https://bitbucket.org/pypy/compatibility/wiki/Home.

[anonymous]

Please update the table above, because

• pysvn supports Python 3 as well as Python 2
• PyMySQL3 0.4 (for Python 3)

[Ryan J Ollos]

We might consider adding mock as a dependency on the trunk or even 1.0-stable since it will be available in Python 3.3+. Many of our unit tests are really integration tests, and mock would give us more control to implement fakes for dependencies. Here is an example that I worked on this evening: log:rjollos.git:t11599.4.

unittest2 is another dependency that we could adopt now and shed when we move to Python 3. Previously we've worked around this by adding trac.tests.compat, and I wasn't eager to add another dependency (comment:17:ticket:11245), but I'd at least like the ability to use assertRaises as a context manager. Maybe we can just add more code to trac.tests.compat, but there may be more useful stuff in unittest2. Adding the dependency doesn't seem so bad since we can drop it when we drop support for Python 2.6.

The two packages would enable us to write more and better tests. I'd find both of these useful since I tend to make mistakes easily and writing more tests is the only way I can improve on this.

[Tim Graham <timograham@…>]

I'll work on Python 3 compatibility using six in #12130.

[Ryan J Ollos]

Subversion 1.9 release notes claims that Python 3.x compatibility ​will be added in the 1.9.x line.

[figaro]

Mercurial is also preparing for Python 3.5+ support. There will be ​no support for the 3.x branch up to Python 3.4.

[anonymous]

PostgreSQL is also supported by ​PyGreSQL.

[0xquad]

Apparently ​subvertpy supports Python 3, which could be an alternative. It claims support for Python 3.5, but I am not sure how well it would cope with 3.x-3.4.

[Ryan J Ollos]

Duplicate of #12130.