On Tue, Jul 7, 2015 at 2:51 PM, Tim Graham <timogra...@gmail.com> wrote:
> I'm a developer on the Django team and we use Trac as our bug tracker. I'm > interested in moving our infrastructure to Python 3, but need Trac to > support Python 3 in order to do so. Django supports Python 2 and 3, so I > have some experience in maintaining a code base that supports both. I > started working on a patch (attached), but as it will be a non-trivial > effort, I wanted to get an initial review and ensure this approach is > agreeable to the Trac team. I also wanted to ensure that when I finish the > patch, someone will be interested in reviewing and committing it relatively > quickly so that it doesn't go stale. My strategy is to attempt to run the > test suite on Python 3 and fix errors, while ensuring the tests pass on > Python 2.7 as a I go. Thanks! Tim > (Peter beat me to it, so there's some redundancy in my message :) I appreciate your offer to help us move to Python 3. We are going to release Trac 1.2 soon. In the 1.3.x development line leading up to 1.4 we'll drop support for Python 2.6, only supporting Python 2.7 (1). Supporting Python 3.3 or 3.4 in 1.3.x is a possibility, but we haven't discussed it lately. The last time I recall discussing it was in (2) (see comment:30 in that ticket). I expect it will be a major effort to have Trac support Python 3. Jun has done some work on it, so he can best comment on the effort required. You may want to read through #10083 (3) to see a list of concerns previously raised, and review the "python3" tickets (4). I recall there being concerns about some of our dependencies not supporting Python 3, such as MySQLdb. With regard to the mechanics of proposing changes, you'll want to base your changes off the current trunk. If you create one monolithic path, it will be difficult for us to review, and will easily become stale, like you suggest. If you were to fork Trac in your favorite DVCS and start stacking up concise changes that lead to supporting Python 3, we can review and incorporate those incrementally. For example, you could submit a patch to fix #12046 (5). You could rebase regularly to avoid the changes that don't get pushed right away from becoming stale. I admit I'm not overly enthusiastic about supporting Python 2.7 and 3.x in the same codebase. I have wanted to make progress towards Python 3 so that we could jump to supporting a minimum of Python 3.3 or 3.4 in development leading up to Trac 1.6. Whether explicitly planned or not, we've been incrementing the minimum Python version supported with each major release (6). Since I've mentioned versions - more about our versioning scheme and roadmap can be found in (7). (1) http://trac.edgewall.org/wiki/TracDev/ApiChanges/1.3 (2) http://trac.edgewall.org/ticket/11600#comment:20 (3) http://trac.edgewall.org/ticket/10083 (4) http://trac.edgewall.org/query?status=!closed&keywords=~python3 (5) http://trac.edgewall.org/ticket/12046 (6) https://groups.google.com/d/msg/trac-dev/nkMUY_8ILF0/xdGVywGqTkYJ (7) http://trac.edgewall.org/wiki/RoadMap#TracsRoadAhead -- 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+unsubscr...@googlegroups.com. To post to this group, send email to trac-dev@googlegroups.com. Visit this group at http://groups.google.com/group/trac-dev. For more options, visit https://groups.google.com/d/optout.
