#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: | |||
Internal Changes: |
Description (last modified by )
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)
follow-up: 3 comment:1 by , 14 years ago
comment:2 by , 14 years ago
Cc: | added |
---|
follow-up: 14 comment:3 by , 14 years ago
comment:4 by , 14 years ago
Cc: | added |
---|
comment:5 by , 14 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 , 14 years ago
Description: | modified (diff) |
---|
Correction: Simon Cross' py3k branch not yet on trunk apparently.
comment:7 by , 14 years ago
Description: | modified (diff) |
---|
Added some data according to what's installed on my machine (Gentoo Linux).
comment:8 by , 14 years ago
Description: | modified (diff) |
---|
Report my early experiments with distribute on Python 3.2 (x64) on Windows 7.
comment:9 by , 14 years ago
Description: | modified (diff) |
---|
Add some infos on db related packages. Nothing actually tested, though.
follow-up: 13 comment:10 by , 14 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.
follow-up: 12 comment:11 by , 14 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.
comment:12 by , 14 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!
comment:13 by , 14 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?
comment:14 by , 14 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 , 14 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 , 12 years ago
Milestone: | next-dev-1.1.x → unscheduled |
---|
The big question is: do we gain anything with this? And if yes, would it be worth the trouble?
comment:17 by , 12 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.
follow-up: 19 comment:18 by , 12 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?).
comment:19 by , 12 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 , 12 years ago
Cc: | added |
---|
comment:21 by , 12 years ago
Cc: | added |
---|
comment:22 by , 11 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 , 11 years ago
Cc: | removed |
---|
comment:24 by , 11 years ago
Cc: | added |
---|
comment:25 by , 10 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 , 10 years ago
Cc: | added |
---|
comment:27 by , 10 years ago
Cc: | added |
---|
comment:28 by , 9 years ago
Description: | modified (diff) |
---|
comment:29 by , 9 years ago
Cc: | added |
---|
comment:30 by , 9 years ago
Cc: | removed |
---|
comment:32 by , 9 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 , 8 years ago
Cc: | added |
---|
comment:34 by , 8 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.
comment:36 by , 8 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 , 8 years ago
Milestone: | unscheduled → 1.3.3 |
---|
comment:39 by , 7 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
comment:40 by , 7 years ago
Cc: | added |
---|
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.