Opened 4 years ago
Last modified 11 months ago
#1419 closed task
Our trac is using Py2 which is EOL ~1yr already — at Version 1
Reported by: | Alex Samorukov | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | wiki | Version: | |
Keywords: | Cc: |
Description (last modified by )
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). 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. Using a lot of py2 dependencies and i do not see any ongoing work to port it to py3
- TracTocMacro - TOC macros for WIKI, trivial to port or remove
Possible options
- 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).
- 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.
- 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