On 10.06.2017 11:38, RjOllos wrote:
On Friday, June 9, 2017 at 11:03:57 PM UTC-7, Peter Suter wrote:
On 10.06.2017 03:43, RjOllos wrote:
> I think it's worth considering to just do a switch to Python
3.5+ in
> Trac 1.5.1 rather than supporting 2.7 and 3.5+.
> * Python 2.7 is end-of-life in 2020 (PEP:0373)
> * Optimistically, Trac 1.6 would be July 2018
> * We could continue to support Trac 1.4.x through 2020
> * Targeting fewer python versions can increase development
velocity on
> the trunk
> * We can take advantage of the improvements in Python3 without
concern
> for a six compatibility layer
> * Backward compatibility for old python versions will likely
continue
> to be less important with the adoptions of containers and other
> isolated environments
>
> I would like to look to the future, improve my proficiency in the
> latest versions of Python focus and focus on adding features. It
feels
> like we've had an excessive focus on the past (e.g. active
development
> supporting Python 2.5 continues for Trac 1.0-stable) and I think it
> hinders the project. I can think of some counterpoints, I just
don't
> think any of them are as important as the points I've listed.
Django
> is dropping support for Python2 in the next major release (1).
>
> Are there any arguments for needing to continue to have the latest
> stable release run on Python 2.7 in mid-to-late 2018? It would
seem to
> me that anyone wanting to stay with the latest Trac can spend
the next
> 12-18 months on their migration plan for this tiny web app.
>
> - Ryan
Sounds reasonable to me, personally. My impression has also been that
the project suffers from this "focus on the past". (I would include
"still using SVN" and "contribution model by patches" here.)
I have on my near-term todo list to writeup steps for contributing
when working from a GitHub fork. It's been discussed in a few tickets
over the past several years.
I have some experience working with SubGit and the SVN-Git mirroring
works pretty well. If we configured SubGit we could commit directly to
Git or SVN. I'd also be fine with setting Subversion read-only and
working primarily from Git. SubGit is useful for that case as well.
There's some discussion about this in Lynx #41.
[OT: I wonder if it would be possible to create a GitHub bot that
posts
all GitHub issues, PR's and comments to Trac tickets, and a Trac
plugin
that posts Trac replies back to GitHub.]
The Django project has some tooling that might be useful. So far we
get about 1 PR from GitHub per year.
I'm guessing the ability to accept pull-requests will get us more than
ticket synchronization. I know we can setup SVN-Git mirror with SubGit
on the Edgewall server. I'm unsure whether it would also be possible
to mirror between the Git on Edgewall and Git on GitHub with r/w to both.
However, just the ability to commit directly to a Git repository would
be a big step forward in that we could easily grab pull requests from
GitHub and commit them.
The switch to Git seems like biggest potential gain as it would save
some overhead in committing to SVN from a Git repository.
(Potentially Trac<->GitHub ticket synchronization could be a "killer
feature" also for other projects that use GitHub for community exposure,
but need some Trac features for coping with tickets. At least I've seen
such requests a few times in discussions of GitHub Issues. But it's just
an random idea probably not worth the huge effort, I don't have much use
for it myself. Personally, I prefer Mercurial and use hggit to interact
with Git repositories.)
One big concern for me is Mercurial support. The current
MercurialPlugin
means Trac and Mercurial must run on the same Python version. And
Mercurial has long been very opposed to Python 3 support. This now
seems
to have changed somewhat, but I think it's still unclear when it
will be
supported.
https://www.mercurial-scm.org/wiki/SupportedPythonVersions#Python_3.x_support
<https://www.mercurial-scm.org/wiki/SupportedPythonVersions#Python_3.x_support>
https://www.mercurial-scm.org/wiki/Python3
<https://www.mercurial-scm.org/wiki/Python3>
Possibly switching to the server-command protocol would help
there, as
Mercurial could then run on its own separate Python version.
https://trac.edgewall.org/ticket/10411
<https://trac.edgewall.org/ticket/10411>
Thanks, that's a significant factor. It's hard to imagine that
Mercurial would continue to only support Python2 past its end-of-life
and still hope to stay relevant. Maybe some more research is warranted
here, to see if there's been additional discussion about the timeline
for Python3 support beyond what's listed on the wiki.
- Ryan
I found it's been a topic on their last sprint:
https://www.mercurial-scm.org/wiki/4.2sprint#Python_3
There are some details about it in the notes:
https://www.mercurial-scm.org/wiki/4.2sprint/Notes
And there are recent Py3 patches on the mercurial-devel mailing list:
https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-June/thread.html
- Peter
--
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 https://groups.google.com/group/trac-dev.
For more options, visit https://groups.google.com/d/optout.
