Complete Rewrite of github2fedmsg Application

This document will investigate the possibility of rewriting github2fedmsg from scratch.

Elements that could use our attention

Project configuration

Currently uses: Setuptools (setup.py)

Suggested using: Poetry (pyproject.toml)

Reason(s): Easier dependency management, project configuration, testing information etc.

Backend language

Currently uses: Python 2.7.x (now EOLed)

Suggested using: Python 3.10.x (and above)

Reason(s): Benefit from performance improvements, bug fixes, security patches etc. on the language

Base framework

Currently uses: Pyramid

Suggested using: Flask or FastAPI

Reason(s): More knowledge about the suggested ones in the team, streamlined development, more features etc.

Templating implementation

Currently uses: Mako

Suggested using: Jinja

Reason(s): More knowledge about the suggested ones in the team, standardized templating etc.

Authentication library

Currently uses: Velruse

Suggested using: Authlib

Reason(s): Authlib is actively maintained while Velruse had its last update 9 years ago.

Frontend CSS library

Currently uses: Bootstrap 3.1.1 (Fedora)

Suggested using: Updated version of Bootstrap for eg. Boostrap 5

Reason(s): Web interface looks/feels dated and is not responsive to variable widths.

Notification popups

Currently uses: Messenger 1.4.1

Suggested using: Updated version of Messenger or any maintained alternative

Reason(s): Library was last added 8 years back and could use an update.

Interface interactivity

Currently uses: JQuery 1.11.0

Suggested using: Updated version of JQuery for eg. JQuery 3.6.1

Reason(s): Library was last added 9 years back and could use an update.

API modelling

Currently uses: In-place creation of data structures in worker functions

Suggested using: Data validation and typing libraries like Pydantic

Reason(s): Better codebase modularity and readability, auto-validation of API data types etc.

Command line parsing

Currently uses: None. Just making do with stdio and stdout.

Suggested using: Click or any other alternatives

Reason(s): Easy-to-use command line creation, handling of options and commands with auto-generated help etc.

The good and the bad

Advantages

1. In its current state, the project is written in (now EOLed) Python 2.7.x and as Python 3 is currently in active development, the project can benefit from the performance improvements, bug fixes and security patches included in the language itself.

2. The project makes use of a certain set of dependencies, the support of which, have not been ported from Python 2 to Python 3. Porting into Python 3 would necessitate the use of newer dependencies which would be more updated, secure and maintained.

3. In its current state, the project makes use of the Pyramid web framework, the expertise of which the team currently lacks, making it unmaintainable right now. A rewrite using libraries and frameworks that the team is acquainted with would help.

4. The web interface makes use of non-default Mako-based templates that work right now but due to their obscure nature, it can become difficult to debug the templates later. A rewrite of templates using a standardized Jinja format would go a long way.

5. The web interface could use updated versions (or replacements) of unmaintained JavaScript and CSS3 dependencies (for now, it has Bootstrap 3.1.1, Messenger 1.4.1, JQuery 1.11.0 etc.) in order to introduce responsiveness and provide a better look and feel.

6. The API model can be standardized with the use of typing and data validation libraries such as Pydantic instead of forming data structures in the worker function itself, making the code more modular and maintainable in the long run.

Disadvantages

1. The move from Python 2 to Python 3 would require special attention into the finding alternatives for the dependencies which either support only Python 2 or are unmaintained as of 2022. Inability to find those would render the rewrite unsuccessful.

2. In the wake of new ways to interact with an API, some features (eg. web interface, when API is suggested to be used by itself) of the current version have become redundant and a 1:1 rewrite would not help as it would frontport those features too.

3. While reworking the database model, it is possible that the existing dump cannot be fully imported due to the changes introduced in the database schema to better work the newer reimplementation, thereby potentially causing data loss.