Opened 3 years ago

Last modified 3 years ago

#1419 new task

Our trac is using Py2 which is EOL ~1yr already

Reported by: Alex Samorukov Owned by:
Priority: minor Milestone: undecided
Component: wiki Version:
Keywords: Cc:

Description (last modified by Alex Samorukov)

Problem description

We are using EdgeWall trac to manage smartmontools project, as well as few plugins which are written on Py27, which is EOL from January 1, 2020 already. As result py2 is no longer receiving any fixes (including security) and is getting slowly removed from the upstream packages. E.g. in the FreeBSD which we are using to host this instance, trac is already marked as "depricated" and soon will be removed due to py27 dependency.

Upstream project is slowly moving to py3, however it is still in "development" branch only (Trac-1.5.2-py3-none-any.whl). Even after removal from the upstream i will be able to continue to host this trac instance (e.g. using jail and installation using pip2), but it will take more efforts and will give us more and more security concerns.

Installed plugins

Plugins for trac are also written on py2 and will require upgrade or rewrite

plugin description status
ManPageRendererPlugin renders our man pages very easy to port
TracAccountManager Manage Trac user accounts. Critical to have, not ported, complex to port, see
TracRecaptchaRegister small plugin to show google re-captcha on the first reg. Should be trivial to port. depends on TracAccountManager
TracSpamFilter SPAM filtering for trac. Must have. complex to port, porting not yet started
TracTocMacro TOC macros for WIKI very easy to port

Possible options

  1. Start testing Trac 1.5/Devel to see how much efforts would take to move trac to it. Problem is that there is no timeline yet, and plugins still need to be ported (at least TracAccountManager which is very critical to us).
  2. Use other options, e.g. Github, which now provides WIKI, pages and other. Gitlab could be used as an alternative. Downside is that we will have to port our existing pages and wiki to it, however, that should be a one time job. This would also significantly change our release procedure.
  3. Do nothing and support trac/py2 as much as we can, e.g. using jail and self-built py. However, this is insecure and will not help us in the long term

Change History (6)

comment:1 Changed 3 years ago by Alex Samorukov

Description: modified (diff)

comment:2 Changed 3 years ago by Alex Samorukov

Description: modified (diff)

comment:3 Changed 3 years ago by Alex Samorukov

Description: modified (diff)

comment:4 Changed 3 years ago by Alex Samorukov

Description: modified (diff)

comment:5 Changed 3 years ago by Alex Samorukov

Description: modified (diff)

comment:6 Changed 3 years ago by Alex Samorukov

Progress updates:

  • Trac/py3 seems to be stable and functional, despite development status. I was able to run our trac on it locally.
  • But it does not apply to plugins. Porting of the TracAccountManager? not started, same as TracSpamFilter.

So lets keep things for now as is and keep tracking of Trac/py3 progress.

Note: See TracTickets for help on using tickets.