Opened 4 years ago

Last modified 11 months ago

#1419 closed task

Our trac is using Py2 which is EOL ~1yr already — at Version 3

Reported by: Alex Samorukov Owned by:
Priority: minor Milestone:
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

  • ManPageRendererPlugin - renders our man pages. We can get rid of it and use ci to do the same if needed
  • TracAccountManager - Manage Trac user accounts. At the moment it is ported to trac 1.4 (which is still py2). See https://trac-hacks.org/ticket/13720 for the porting information. Critical to have.
  • TracRecaptchaRegister - small plugin to show google re-captcha on the first reg. Should be trivial to port.
  • TracSpamFilter - SPAM filtering for trac. Must have. Branch https://svn.edgewall.org/repos/trac/plugins/trunk/spam-filter has ongoing Trac 1.5 porting commits.
  • TracTocMacro - TOC macros for WIKI, trivial to port or remove

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 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 (3)

comment:1 by Alex Samorukov, 4 years ago

Description: modified (diff)

comment:2 by Alex Samorukov, 4 years ago

Description: modified (diff)

comment:3 by Alex Samorukov, 4 years ago

Description: modified (diff)
Note: See TracTickets for help on using tickets.