DEV Community

DenisC
DenisC

Posted on

Continued Journey on Open Source Projects - Deprecate Python 3.9

My journey on open source projects doesn't stop after making four pull requests for Hacktoberfest last month. Contrary to finding different repos to work on different issues in Hacktoberfest, I'm focusing on one repo this time, namely Open Web Calendar. It is a well organized and maintained repo I worked on in Hacktoberfest, with rigorous tests and Continuous Integration(CI).

The issue I worked on

The issue I worked on is to deprecate Python 3.9, which reaches its End of Life in Oct 2025. The maintainer posted this issue giving a direction of what need to be changed, and mentioning the rationale for this issue, which is to remove Python 3.9 form tests in order to update dependencies which has deprecate Python 3.9.

Challenges I faced

The first challenge I faced was to understand the project structure. The issue is different from the issues I previously worked on, such as bug fixing and implementing new features, which allowed me to only focus on a part of the codes. This issue instead requires understanding the structure of the whole projects, then searching for relevant files and making changes accordingly. To get a better understanding on the repo, I used Repomix, a tool I studied in previously lab, to pack the info of the repo into an .xml file and send it to AI to get a brief summary of the project structure.

After understanding the project structure, I had to figure out which files should be changed. Based on the brief explanation from the maintainer, I did some research on how to handle deprecating a programming language version in open source project, and was able to narrow down the scope of changes to the following files:

  1. documentation which mention the use of Python 3.9, located in docs/dev/
  2. yml files in .github/workflows, which controls the CI process
  3. tox.ini, configuration file for tox, the tool used in Python testing
  4. pyproject.toml, configuration file for the project

The most tedious process was to find which part of the files should be changed. I used different approaches to do it, which include checking relevant files one by one manually, and use commands such as git grep py39. I had to pay careful attentions to spot out and remove Python 3.9 in the files, as Python 3.9 might appear in different forms, such as py39, python: ["3.9", ...], and python3.9. Moreover, as the maintainer intended to just remove the tests for Python 3.9 while still allowing users to install the app with Python 3.9, I cannot blindly erase all py39 syntax. For example, requires-python = ">=3.9" in pyproject.toml was kept.

After checking all the .yml in .github/workflows/, .md in docs/dev/, tox.ini and pyproject.toml and making relevant changes, I committed those changes, but new problems arose. As ruff now is run based on Python 3.10 instead of 3.9, syntax in some of the .py files need to be changed. Luckily, the logs from ruff clearly gave hints to fix the syntax, so I changed the syntax accordingly, pushed the codes, and made a pull request, which was eventually accepted by the maintainer.

Lessons learnt

First, I've learnt the importance of utilizing tools, which can save a lot of time in software development. From automation tools such as GitHub Actions and tox, to linter such as ruff, an even Repomix I used in the process of solving the issues, all these tools smoothen the software development process in different aspects, from running tests, fixing syntax, and solving an issue.
Moreover, I have become more confident in solving an issues before I have full knowledge about the issues. Unprecedented issues may arise when we are working on an issue, just like how the ruff check failed at the first time, but clues will appear in the progress, and community such as the maintainer and other developers will offer a helping hand. Finally, I now better appreciate the importance of clear logging. On one hand, the logging from ruff guided me in fixing the syntax. On the other hand, my efforts in writing clear commit messages and summary of changes were acknowledged by the maintainer, who could therefore quickly understand and approve the changes.

Top comments (0)