[Trac-dev] Python3 question

Discussion:

anton

2016-03-14 19:28:22 UTC

Hi,

this year I wanted to try to switch
to python3.

I tried to install packages on python 3.5.1
- Genshi: worked
- Babel: worked
- Trac: I got a message thats its only pyton2 compatible

So my little question: is there a roadmap for python3 support
in trac?

Thanks for a hint

Anton

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trac-dev+***@googlegroups.com.
To post to this group, send email to trac-***@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-dev.
For more options, visit https://groups.google.com/d/optout.

RjOllos

2016-03-15 06:13:01 UTC

Permalink

Post by anton
Hi,
this year I wanted to try to switch
to python3.
I tried to install packages on python 3.5.1
- Genshi: worked
- Babel: worked
- Trac: I got a message thats its only pyton2 compatible
So my little question: is there a roadmap for python3 support
in trac?
Thanks for a hint
Anton

There are recent discussions about this on the mailing list.
https://groups.google.com/forum/#!msg/trac-dev/Rxqr-4Y0fTU/iCrNqOFj1DgJ
https://groups.google.com/forum/#!topic/trac-dev/KqWPQWuZ63k

The summary is, we'll add Python 3 support in 2016 and Trac 1.4 will
support Python 2.7, Python 3.3+. Trac 1.4 will be released in 2017, most
likely. Also likely, Genshi will be dropped as the templating engine in
favor of Jinja2.

What is your reason for wanting to run on Python 3.5?

- Ryan

Olemis Lang

2016-03-15 20:02:53 UTC

Permalink

[...]

Post by RjOllos
What is your reason for wanting to run on Python 3.5?

[...]

I do not know about neither the OP intentions nor the roadmap and
goals for Trac Python 3 support but if I was upgrading to Python 3 I'd
definitely look for 3.5 as a target .
--
Regards,

Olemis - @olemislc

Apache™ Bloodhound contributor
http://issues.apache.org/bloodhound
http://blood-hound.net

Brython committer
http://brython.info
http://github.com/brython-dev/brython

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

anton

2016-03-15 22:35:42 UTC

Permalink

Hi Ryan,

I am developping on windows where I use
- python 2.7 (with tools like django)
- C# (Visual Studio 2008) for some stuff,
- php (piwik)
- apache ( with a ntlm module to allow single sign on in out intranet)
- sometime python packages wich contain native C files
(which are compiled by my Visual Studio,
for example the apache modwsgi module)

Now all python 3.0 - 3.4 use Visual Studio 2010 which is
no more actual, and since I bought a new version (my company)
I bought Visual Studio 2015 of course.

Now:
- python 3.5 is based on Visual Studio 2015
- the actual php 7 windows binaries are built with Visual Studio 2015
- the actual http://www.apachelounge.com windows apache binaries
are built with Visual Studio 2015 ( there exist binaries built with
other Visual Studio versions but Visual Studio 2008 is *no* more
supported.

So I would like to make the big jump directly to python 3.5,
because I am more comfortable when all my
modules are based on the same compiler so I am sure
that all (necessary) components are binary compatible.

Anton

Post by RjOllos

There are recent discussions about this on the mailing list.
https://groups.google.com/forum/#!msg/trac-dev/Rxqr-4Y0fTU/iCrNqOFj1DgJ
https://groups.google.com/forum/#!topic/trac-dev/KqWPQWuZ63k
The summary is, we'll add Python 3 support in 2016 and Trac 1.4 will
support Python 2.7, Python 3.3+. Trac 1.4 will be released in 2017, most
likely. Also likely, Genshi will be dropped as the templating engine in
favor of Jinja2.
What is your reason for wanting to run on Python 3.5?
- Ryan

Tim Graham

2016-03-16 00:30:36 UTC

Permalink

If Python 3 support for Trac won't be released until 2017, I think there's
no need to support Python 3.3 which is end-of-life in September 2017
(already the most recent release of Django supports Python 3.4+, for
example). I think Python 3.5+ would be a fine target, but if people feel
that Python 3.4 support is important for some reason, it might not add much
work. As long as we must maintain Python 2.7 support, we're fairly limited
in the Python 3 features we can use anyway.

Post by anton
Hi Ryan,
I am developping on windows where I use
- python 2.7 (with tools like django)
- C# (Visual Studio 2008) for some stuff,
- php (piwik)
- apache ( with a ntlm module to allow single sign on in out intranet)
- sometime python packages wich contain native C files
(which are compiled by my Visual Studio,
for example the apache modwsgi module)
Now all python 3.0 - 3.4 use Visual Studio 2010 which is
no more actual, and since I bought a new version (my company)
I bought Visual Studio 2015 of course.
- python 3.5 is based on Visual Studio 2015
- the actual php 7 windows binaries are built with Visual Studio 2015
- the actual http://www.apachelounge.com windows apache binaries
are built with Visual Studio 2015 ( there exist binaries built with
other Visual Studio versions but Visual Studio 2008 is *no* more
supported.
So I would like to make the big jump directly to python 3.5,
because I am more comfortable when all my
modules are based on the same compiler so I am sure
that all (necessary) components are binary compatible.
Anton

Post by RjOllos

There are recent discussions about this on the mailing list.
https://groups.google.com/forum/#!msg/trac-dev/Rxqr-4Y0fTU/iCrNqOFj1DgJ
https://groups.google.com/forum/#!topic/trac-dev/KqWPQWuZ63k
The summary is, we'll add Python 3 support in 2016 and Trac 1.4 will
support Python 2.7, Python 3.3+. Trac 1.4 will be released in 2017, most
likely. Also likely, Genshi will be dropped as the templating engine in
favor of Jinja2.
What is your reason for wanting to run on Python 3.5?
- Ryan

Ryan Ollos

2016-03-16 09:51:09 UTC

Permalink

Post by Tim Graham
If Python 3 support for Trac won't be released until 2017, I think there's
no need to support Python 3.3 which is end-of-life in September 2017
(already the most recent release of Django supports Python 3.4+, for
example). I think Python 3.5+ would be a fine target, but if people feel
that Python 3.4 support is important for some reason, it might not add much
work. As long as we must maintain Python 2.7 support, we're fairly limited
in the Python 3 features we can use anyway.

Thanks. I haven't worked with Python3 much, but I guess it's worth
considering supporting Python 3.4+.

If we do support Python 3.3 in Trac 1.4 though, and stick to a major
release every 12-18 months, we would extrapolate nicely on the pattern
Christian previously noted (1).

Trac 0.11 - last version to work with Python 2.3
Trac 0.12 - last version to work with Python 2.4
Trac 1.0 - last version to work with Python 2.5
Trac 1.2 - last version to work with Python 2.6
Trac 1.4 - last version to work with Python 3.3 (released Jun 2017?)
Trac 1.6 - last version to work with Python 3.4 (released Jan 2019?)

The release dates line up fairly nicely with the end-of-life for the Python
releases (2), preceding them by just a few months.

- Ryan

(1) https://groups.google.com/d/msg/trac-dev/nkMUY_8ILF0/xdGVywGqTkYJ
(2) https://docs.python.org/devguide/index.html#branchstatus

Tim Graham

2016-08-22 20:14:34 UTC

Permalink

I don't think releasing a new version of Trac and having it support a
Python version whose support ends a few months later brings much value.

Django adopted this policy, "Typically, we will support a Python version up
to and including the first Django LTS release whose security support ends
after security support for that version of Python ends. For example, Python
3.3 security support ends September 2017 and Django 1.8 LTS security
support ends April 2018. Therefore Django 1.8 is the last version to
support Python 3.3."

The idea is that if you insistent on using an old version of Python, are
you likely to want the latest and greatest Trac / Django / <third-party
library>?

Post by Ryan Ollos

Post by Tim Graham
If Python 3 support for Trac won't be released until 2017, I think
there's no need to support Python 3.3 which is end-of-life in September
2017 (already the most recent release of Django supports Python 3.4+, for
example). I think Python 3.5+ would be a fine target, but if people feel
that Python 3.4 support is important for some reason, it might not add much
work. As long as we must maintain Python 2.7 support, we're fairly limited
in the Python 3 features we can use anyway.

Thanks. I haven't worked with Python3 much, but I guess it's worth
considering supporting Python 3.4+.
If we do support Python 3.3 in Trac 1.4 though, and stick to a major
release every 12-18 months, we would extrapolate nicely on the pattern
Christian previously noted (1).
Trac 0.11 - last version to work with Python 2.3
Trac 0.12 - last version to work with Python 2.4
Trac 1.0 - last version to work with Python 2.5
Trac 1.2 - last version to work with Python 2.6
Trac 1.4 - last version to work with Python 3.3 (released Jun 2017?)
Trac 1.6 - last version to work with Python 3.4 (released Jan 2019?)
The release dates line up fairly nicely with the end-of-life for the
Python releases (2), preceding them by just a few months.
- Ryan
(1) https://groups.google.com/d/msg/trac-dev/nkMUY_8ILF0/xdGVywGqTkYJ
(2) https://docs.python.org/devguide/index.html#branchstatus

RjOllos

2016-08-24 00:52:11 UTC

Permalink

Post by Tim Graham
I don't think releasing a new version of Trac and having it support a
Python version whose support ends a few months later brings much value.
Django adopted this policy, "Typically, we will support a Python version
up to and including the first Django LTS release whose security support
ends after security support for that version of Python ends. For example,
Python 3.3 security support ends September 2017 and Django 1.8 LTS security
support ends April 2018. Therefore Django 1.8 is the last version to
support Python 3.3."
The idea is that if you insistent on using an old version of Python, are
you likely to want the latest and greatest Trac / Django / <third-party
library>?

I agree. Trac has been more than generous in supporting old versions of
Python, PostgreSQL, etc ..., to the point that it slows development effort.
My aim with the "compatible distros" table was to guide us in developing
rules for which versions we'll support, rather than making arbitrary
choices.
https://trac.edgewall.org/wiki/TracDev/ApiChanges/1.3#CompatibleDistros

Based on the platforms listed on the table (the ones in bold), we could
start supporting Python 3.4+ rather than 3.3+ in Trac 1.3.1+.

- Ryan

Ryan Ollos

2016-03-16 09:43:09 UTC

Permalink

Are you developing Trac or Trac plugins? If not, then I think you'll be
investing a lot of working in moving your Trac installation to Python 3.5
with little to gain.

Alternatively, you can isolate your Trac installation with a virtual
environment and this is good practice even if you don't have multiple
Python installations on your system. If you aren't doing development for
Trac then you'll never even notice that it's running a different Python
version after the initial setup.

I would recommend focusing on isolating your environments rather than
keeping everything compatible in a single environment. Anyway, you don't
really have another other option right now unless you want to modify Trac
yourself. You could probably run a "development stable" (1) release (e.g.
1.3.1, which might be released in July or August) on Python 3.5 later this
year, but you'll be taking on the burden of testing stable but unproven
code. We certainly don't mind since we need users to test and report
issues, but beware of the caveats (2) and make sure you are up for them
before taking that step.

- Ryan

(1) https://trac.edgewall.org/wiki/RoadMap#MilestoneCategories
(2) https://trac.edgewall.org/wiki/TracDownload#LatestDevRelease