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
- Templating implementation
- Authentication library
- Currently uses: VelruseSuggested using: AuthlibReason(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 5Reason(s): Web interface looks/feels dated and is not responsive to variable widths.
- Notification popups
- Currently uses: Messenger 1.4.1Suggested using: Updated version of Messenger or any maintained alternativeReason(s): Library was last added 8 years back and could use an update.
- Interface interactivity
- Currently uses: JQuery 1.11.0Suggested using: Updated version of JQuery for eg. JQuery 3.6.1Reason(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 functionsSuggested using: Data validation and typing libraries like PydanticReason(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 alternativesReason(s): Easy-to-use command line creation, handling of options and commands with auto-generated help etc.
The good and the bad
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.
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.
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.
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.
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.
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.
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.
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.