[patch] PoC Python3 support for Trac

87 views
Skip to first unread message

Rick van der Zwet

unread,
Jan 9, 2020, 6:22:49 PM1/9/20
to Trac Development
Hi Folks,

Since python2 is EOL and scheduled to be removed from software repositories like Debian and FreeBSD, trac is also in danger of getting removed, since no Python 3 support is working yet.

I could spend my time trying to change all my Trac instances to a alternative, how-ever I decided to give a blunt-axe approach in converting the trunk code to be python 3 compatible (dropping support for python 2 all together). After 6 hours hacking on the codebase I got myself a 'hello world' version of Trac on Python3.

To reproduce this 'hello world' Trac on Python3:
 
    $ <<<apply patch against trunk r17226 (latest)>>>

    $ mkdir ~/tracenvs
    $ rm -Rf ~/tracenvs/project1; PYTHONPATH=. python3 ./trac/admin/console.py ~/tracenvs/project1 initenv project1 sqlite:db/trac.db
    $  PYTHONPATH=.  python3 ./trac/web/standalone.py -e ~/tracenvs -p 8000


I be happy to spend some more time on it, ironing out most issues and making sure all test cases are working again. How-ever I do like to make sure this is the right way forward and/or I am not duplicating work.

Kind regards,
Rick


poc-trac-trunk-patch-python-3-support.patch

Steffen Hoffmann

unread,
Jan 10, 2020, 1:29:49 AM1/10/20
to trac...@googlegroups.com
IIRC Trac 1.5 dev releases shall prepare Trac 1.6 that will work with Phython3. Pushing Trac-hacks Trac plugin code in a broad sense is rather weak yet.
Anyway, more developer ressources will help to make it happen in a convenient time. So please pick up corresponding discussions here, review Trac dev code and join collaborativ effort for Track plugins as much as you can. Thanks for asking!


Sincerely,

Steffen Hoffmann

Peter Suter

unread,
Jan 10, 2020, 12:54:02 PM1/10/20
to trac...@googlegroups.com

Hi,

Sounds great! Have you considered attaching your patch to a ticket so it does not get lost?
Also, are you aware of this ticket: https://trac.edgewall.org/ticket/12130#comment:51
It points to rjollos.git@t12130_python3.1 as the latest (but probably far from up-to-date) status at porting Trac to Python3.
How does your patch compare to that?

Cheers,
Peter

Rick van der Zwet

unread,
Jan 11, 2020, 8:04:50 AM1/11/20
to trac...@googlegroups.com
On 2020-01-10 07:29, Steffen Hoffmann wrote:
> Am 10. Januar 2020 00:20:03 MEZ schrieb Rick van der Zwet
> <in...@rickvanderzwet.nl>:
>
>> Hi Folks,
>>
>> Since python2 is EOL and scheduled to be removed from software
>> repositories like Debian and FreeBSD, trac is also in danger of
>> getting removed, since no Python 3 support is working yet.
>>
>> I could spend my time trying to change all my Trac instances to a
>> alternative, how-ever I decided to give a blunt-axe approach in
>> converting the trunk code to be python 3 compatible (dropping support
>> for python 2 all together). After 6 hours hacking on the codebase I
>> got myself a 'hello world' version of Trac on Python3.
>> ...
>>
>> I be happy to spend some more time on it, ironing out most issues and
>> making sure all test cases are working again. How-ever I do like to
>> make sure this is the right way forward and/or I am not duplicating
>> work.
>
> IIRC Trac 1.5 dev releases shall prepare Trac 1.6 that will work with
> Phython3.

Which branch is this work based on? I was basing my work of @trunk,
which did not have any Python3 support at all.

> Pushing Trac-hacks Trac plugin code in a broad sense is rather weak
> yet.

To be honest I do not worry about the track-hacks trac plugin code yet,
I first like to see the core work with Python 3.

> Anyway, more developer ressources will help to make it happen in a
> convenient time. So please pick up corresponding discussions here

Where will this be?

> review Trac dev code and join collaborativ effort for Track plugins as
> much as you can. Thanks for asking!

Thanks for your answers, I am not a trac developer, so still finding my
way around the project. More pointers welcome :-)

Kind regards,
Rick

Rick van der Zwet

unread,
Jan 11, 2020, 8:24:59 AM1/11/20
to trac...@googlegroups.com
On 2020-01-10 18:53, Peter Suter wrote:
> On 10/01/2020 00:20, Rick van der Zwet wrote:
..
>> I could spend my time trying to change all my Trac instances to a
>> alternative, how-ever I decided to give a blunt-axe approach in
>> converting the trunk code to be python 3 compatible (dropping support
>> for python 2 all together). After 6 hours hacking on the codebase I
>> got myself a 'hello world' version of Trac on Python3.
...
>> I be happy to spend some more time on it, ironing out most issues and
>> making sure all test cases are working again. How-ever I do like to
>> make sure this is the right way forward and/or I am not duplicating
>> work.
>
> Sounds great! Have you considered attaching your patch to a ticket so
> it does not get lost?

Not allowed: "Maximum attachment size: 512.0 KB:

> Also, are you aware of this ticket:
> https://trac.edgewall.org/ticket/12130#comment:51
> It points to rjollos.git@t12130_python3.1 as the latest (but probably
> far from up-to-date) status at porting Trac to Python3.
> How does your patch compare to that?

I did not bother with any Python 2 compatibility, as such did not use
the six library. Secondly the pointed rjollos.git@t12130_python3.1
seemed rather old and outdated and using python 3.1 as base version.
Since I am no trac-developer, I 'trusted' svn@trunk
(https://svn.edgewall.org/repos/trac/trunk/) to be the latest, how-ever
this is just a lucky guess by me.

Basically I first processed all files with ``2to3'' (the python2 to
python3 converter tooling) and next I fixed issues which mainly involved
changes with python3 default representation of strings and continued
doing so until I could load the first WikiStart without errors on the
console and log file.

Kind regards,
Rick



Peter Suter

unread,
Jan 11, 2020, 8:57:14 AM1/11/20
to trac...@googlegroups.com
On 11.01.2020 14:24, Rick van der Zwet wrote:
>> Sounds great! Have you considered attaching your patch to a ticket so
>> it does not get lost?
>
> Not allowed: "Maximum attachment size: 512.0 KB:

Maybe you could ZIP it.
Or even better might be to link to a forked repository of
https://github.com/edgewall/trac

> I did not bother with any Python 2 compatibility, as such did not use
> the six library.

As I understand it this is fine, as Ryan had also mentioned a plan to
move towards that.

> Secondly the pointed rjollos.git@t12130_python3.1
> seemed rather old and outdated and using python 3.1 as base version.

What Python version do you target?
I'm not sure the branch name does refer to python3.1 or rather to
something like "python3.x experiment branch revision .1".
I thought Python 3.3+ was already assumed.
Is there a big pain in supporting that?
It seems only 3.5+ are not EOL yet.
https://devguide.python.org/#status-of-python-branches
Although supporting some Linux distributions would imply quite old versions.
https://trac.edgewall.org/wiki/TracDev/ApiChanges/1.3#CompatibleDistros

> Since I am no trac-developer, I 'trusted' svn@trunk
> (https://svn.edgewall.org/repos/trac/trunk/) to be the latest, how-ever
> this is just a lucky guess by me.

That's correct. The Git repository trunk branch is also automatically
mirrored and up-to-date. https://github.com/edgewall/trac

> Basically I first processed all files with ``2to3'' (the python2 to
> python3 converter tooling) and next I fixed issues which mainly involved
> changes with python3 default representation of strings and continued
> doing so until I could load the first WikiStart without errors on the
> console and log file.

Have you tried the tests yet?

Cheers,
Peter

Rick van der Zwet

unread,
Jan 11, 2020, 8:04:46 PM1/11/20
to trac...@googlegroups.com
On 2020-01-11 14:57, Peter Suter wrote:
> On 11.01.2020 14:24, Rick van der Zwet wrote:
>>> Sounds great! Have you considered attaching your patch to a ticket so
>>> it does not get lost?
>>
>> Not allowed: "Maximum attachment size: 512.0 KB:
>
> Maybe you could ZIP it.
> Or even better might be to link to a forked repository of
> https://github.com/edgewall/trac

Thanks for the compression tip, added as compressed file to the ticket
for future references.

> That's correct. The Git repository trunk branch is also automatically
> mirrored and up-to-date. https://github.com/edgewall/trac
>
>> Basically I first processed all files with ``2to3'' (the python2 to
>> python3 converter tooling) and next I fixed issues which mainly
>> involved changes with python3 default representation of strings and
>> continued doing so until I could load the first WikiStart without
>> errors on the console and log file.
>
> Have you tried the tests yet?

Only the basic 'manual' ones, no automated testing done yet. Revised
patch now also allows using all default pages, editing and making
tickets, etc.

Kind regards,
Rick
2020-01-12-poc-v2-trac-trunk-patch-add-python3-support.patch

Rick van der Zwet

unread,
Jan 12, 2020, 8:34:02 PM1/12/20
to trac...@googlegroups.com
Started working on the automated test-cases. Managed to munch a whole
bunch of them, still some left. Large number are still caused due to
unstable sorting of dictionaries causing arguments in URI be ordered
differently, guess it need some more sorting somewhere.

Attached the latest patch. Who to contact to get the patch included in
trunk when done?

Kind regards,
Rick
2020-01-13-poc-v3-trac-trunk-patch-add-python3-support.patch

Steffen Hoffmann

unread,
Jan 12, 2020, 10:16:47 PM1/12/20
to trac...@googlegroups.com
On 2020-01-13 02:33, Rick van der Zwet wrote:
> ...
>Attached the latest patch. Who to contact to get the patch included in
>trunk when done?

You're at the right place for getting developers attention, no extra effort needed so far.

As mentioned before, for easier testing, commenting and code adoption a repository based approach, i. e. pull request from a fork of trunk containing a commented series of your changes at GitHub would be preferred over an all-in-one patch.

For getting an idea of how it shall finally look like you may read changeset and Ticket comments for the Genshi -> Jinja2 migration in

https://trac.edgewall.org/ticket/12639



Steffen Hoffmann

RjOllos

unread,
Jan 13, 2020, 7:51:24 PM1/13/20
to Trac Development
Good points.

I expect it's going to be difficult for anyone lacking experience on the project to produce a patch that we can use. I don't want to discourage anyone that is up to the task but trying to be realistic so that it doesn't feel like wasted effort.

I'm hoping to find time to work on the Python 3 port soon. Any attempts I make will need a lot of help from the experts: you, Jun and Christian.

I think we should target Python 3.6+ considering 3.5 is EOL in Q3 and the most optimistic official release of a stable Trac w/ Python 3 would be mid-year.

- Ryan

RjOllos

unread,
Jan 28, 2020, 2:38:30 PM1/28/20
to Trac Development
See #12130 for recent activity on the changes proposed by Jun.


- Ryan
Reply all
Reply to author
Forward
0 new messages