Edgewall Software
Modify

Opened 8 years ago

Closed 2 years ago

Last modified 7 months ago

#10083 closed enhancement (duplicate)

Make Trac work with Python 3

Reported by: Remy Blank Owned by:
Priority: normal Milestone:
Component: general Version:
Severity: normal Keywords: python3
Cc: leho@…, Thijs Triemstra, gabriele.svelto@…, Ryan J Ollos, py.hieroglyph@…, Jun Omae, Arthur.Solomon@…, t17-0by@… Branch:
Release Notes:
API Changes:

Description (last modified by Ryan J Ollos)

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.

Attachments (0)

Change History (40)

comment:1 by Eli Carter, 8 years ago

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.

comment:2 by lkraav <leho@…>, 8 years ago

Cc: leho@… added

in reply to:  1 ; comment:3 by Christian Boos, 8 years ago

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? ;-)

comment:4 by Thijs Triemstra, 8 years ago

Cc: Thijs Triemstra added

comment:5 by Christian Boos, 8 years ago

Description: modified (diff)

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

comment:6 by Christian Boos, 8 years ago

Description: modified (diff)

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

comment:7 by Remy Blank, 8 years ago

Description: modified (diff)

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

comment:8 by Christian Boos, 8 years ago

Description: modified (diff)

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

comment:9 by Christian Boos, 8 years ago

Description: modified (diff)

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

comment:10 by osimons, 8 years ago

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.

comment:11 by Felix Schwarz, 8 years ago

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.

in reply to:  11 comment:12 by Christian Boos, 8 years ago

Description: modified (diff)

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!

in reply to:  10 comment:13 by Thijs Triemstra, 8 years ago

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?

in reply to:  3 comment:14 by Eli Carter, 8 years ago

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.

comment:15 by Christian Boos, 8 years ago

Description: modified (diff)

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.

comment:16 by Christian Boos, 7 years ago

Milestone: next-dev-1.1.xunscheduled

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

comment:17 by Remy Blank, 7 years ago

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.

comment:18 by Christian Boos, 7 years ago

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?).

in reply to:  18 comment:19 by Jun Omae, 7 years ago

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.

comment:20 by Alex Willmer <alex@…>, 7 years ago

Cc: alex@… added

comment:21 by Ryan J Ollos <ryano@…>, 7 years ago

Cc: ryano@… added

comment:22 by anonymous, 6 years ago

Please update the table above, because

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

comment:23 by Ryan J Ollos, 6 years ago

Cc: ryano@… removed

comment:24 by Gabriele Svelto <gabriele.svelto@…>, 6 years ago

Cc: gabriele.svelto@… added

comment:25 by Ryan J Ollos, 5 years ago

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.

comment:26 by Ryan J Ollos, 5 years ago

Cc: Ryan J Ollos added

comment:27 by Mark Cooke <py.hieroglyph@…>, 4 years ago

Cc: py.hieroglyph@… added

comment:28 by Ryan J Ollos, 4 years ago

Description: modified (diff)

comment:29 by Jun Omae, 4 years ago

Cc: Jun Omae added

comment:30 by Alex Willmer <alex@…>, 4 years ago

Cc: alex@… removed

comment:31 by Tim Graham <timograham@…>, 4 years ago

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

comment:32 by Ryan J Ollos, 3 years ago

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

comment:33 by Arthur Solomon <Arthur.Solomon@…>, 3 years ago

Cc: Arthur.Solomon@… added

comment:34 by figaro, 3 years ago

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

Last edited 3 years ago by Jun Omae (previous) (diff)

comment:35 by anonymous, 3 years ago

PostgreSQL is also supported by PyGreSQL.

Last edited 3 years ago by Jun Omae (previous) (diff)

comment:36 by 0xquad, 3 years ago

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.

comment:37 by Christian Boos, 3 years ago

Milestone: unscheduled1.3.3

comment:38 by Ryan J Ollos, 2 years ago

Milestone: 1.3.3

Duplicate of #12130.

comment:39 by Ryan J Ollos, 2 years ago

Resolution: duplicate
Status: newclosed

comment:40 by Thomas Lae <t17-0by@…>, 20 months ago

Cc: t17-0by@… added

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The ticket will remain with no owner.
The resolution will be deleted.
to The owner will be changed from (none) to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.