Open Source Contribution - Release 0.4 Part 2

Integrating Style Guide Enforcement

PEP8 Speaks is one of the many tools to help enforce style in a GitHub project. It is easily integratabtle with any public GitHub project by following the installation instructions from the following link:


Once it is integrated, it can be configured to check for style and linting errors in the changes of Pull Requests. A pep8speaks bot will respond in a comment of the PR if there were any issues. 

Similarly to PEP8 Speaks, Flake8 is a good tool to use when checking for style and linting errors locally. In order to install Flake8, you will need to type in the following command: "python -m pip install flake8". After installation you can run the "flake8" command to either check the whole project or specific files. To check your whole project, go into the root folder of your project and type the following command: "flake8 .". To check specific files: "flake8 example/example.py".

In the configuration files of both tools, you can configure which errors need to be ignored and which errors need to be checked by both tools. I will give examples showing how to do this in the next section.

Integrating PEP8 Speaks and Flake8 into pySearch

For part 2 of my Release 0.4 I was focusing on our internal pySearch project. The owner of the project has restructured the project and I needed to go back into my previous Pull Requests and edit them to ensure that they would fit into the new structure. We agreed to hold off any merging until the new structure is in place to ensure that there are no problems with the integration of the new structure. After ensuring that everything has been refactored, I decided that it would be beneficial to explore Flake8 and PEP8 Speaks for pySearch.

In order to test the project with Flake8, I followed the steps for installation and execution that I stated in the above section. It displayed a few existing errors within the project. The first step was to create a "setup.cfg" file that would contain the configurations and ignore lists for Flake8 checks. I thought that the best way to integrate Flake8 into the project was to first ignore all existing errors in the project and allow others to contribute and remove these errors in an issue that I created. The initial setup.cfg file can be seen below.

After setting up Flake8 and ensuring that there are no remaining errors, I continued to explore PEP8 Speaks, which would do automatic checking on every Pull Requests that comes into the project. The process was very similar, however I needed to create a separate file to contain the configurations for PEP8 Speaks, which is called ".pep8speaks.yml". The contents of this file can be seen below. 

As you can see, the ignore lists in both configuration files are the same since we want to keep Flake8 and PEP8 Speaks consistent with each other. In addition, "diff_only: True" configuration lets PEP8 Speak know that the checks should only be performed on the changes of the Pull Request that it's checking. When PEP8 Speaks was integrated with pySearch, I tested the performance of this tool through a new pull request, where I put a change that will cause a linting error on purpose. As expected, the pep8speaks bot commented on my pull request, informing me of the issues. This can be seen from the picture below.


PEP8 Speaks and Flake8 have noticed two errors when I inserted extra spaces before and after the bracket. Throughout this process of integration and testing, I ensured that pySearch project has all the tools now to perform checks for style and linting errors in the future.

Issue for Flake8 / PEP8 Speaks integration: https://github.com/jrkong/pySearch/issues/29

Pull Requests:
Issue to fix Flake8 / PEP8 Speaks errors: https://github.com/jrkong/pySearch/issues/35


Working as a Code Reviewer for pySearch

In addition to making some contributions to pySearch, I also experienced some moderator work by reviewing a couple Pull Requests that were created by the owner of the project.


In this PR, the owner added a section for testing instructions to the README.md. I reviewed this section and gave thumbs up to the owner that it was ready to be merged. The instructions were well written. After speaking with the owner, this PR was merged.


This PR was larger than the previous one and included a lot of additions and modifications to the documentation, as well as tools for PIP installation of the project. I noticed that there was a merge conflict and asked the owner to resolve this before merging. In addition, Flake8 and PEP8 Speaks was just integrated within the project, so I asked the owner to ensure that his code passes the checks before merging. After he finished working on these two suggestions, I reviewed his code again and he merged it after I gave it thumbs up.

Overall, being a moderator of a project is fun but time consuming, because you need to go over code and documentation and ensure that everything works and looks as expected.








Comments

Popular posts from this blog

Progress in Open Source

Planning Pandas Contributions for the Next Month

Another Dropna Bug in Pandas