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

Post a Comment

Popular posts from this blog

Another Dropna Bug in Pandas

Image
Another Dropna Bug in Pandas This year I fixed a few bugs that dealt with NaN values and more specifically the Dropna function in Pandas. Every bug like this made me more and more interested in fixing behaviour that is not consistent across the code base, specifically how the functions deal with non existent values. Some functions have a dropna argument. When set to true, the function should drop columns/rows that contain missing values and when set to false, the function should keep columns/rows that contain missing values. Currently, some functions deal well with NaN values, however there are functions that either produce buggy behaviour with NaN or don't deal with it consistently across the code base. This week I found another bug like this and I will be working on it throughout next week. Issue https://github.com/pandas-dev/pandas/issues/10772 The creator of the issue noticed inconsistent behaviour when using the dropna argument inside the crosstab function...
Read more

Unit Tests in Pandas

Image
Contributing Unit Tests to Pandas The issue that I decided to work on this week was one of the easier issues discussed in my last blog, however it gave me valuable experience with unit testing in Python and Pandas specifically. I decided to start my 2019 open-source contributions with unit testing because I haven't had much experience with unit testing previously in Python.  Overview of the Issue https://github.com/pandas-dev/pandas/issues/21205 As I previously stated in my last blog, this issue shed light on an issue with using NaT when converting a Series to a Period using the dt.to_period('D') function. Other datetime64[ns] objects with values have no problem converting into a Period, however when a NaT was passed in, it stayed as datetime64[ns]. NaT represents a missing value for datetime objects. Since the issue was posted, it has been resolved with current updates to the master branch. However, one of the moderators asked for unit tests that would ens...
Read more

Progress in Open Source

Image
Progress in Open Source In this blog I will talk about my journey and progress in open source development so far. I've been really enjoying working on real world projects that are used by many people every day. It is not only challenging as every Pull Request required me to perform research in order to understand the issue and solve it, but it is also rewarding because I acquire hands-on experience that is much needed and also contribute to the open source community that I am very fond of now. Open Source Timeline Summary I started exploring open source development during September of 2018. I had to learn a lot of useful tools that Git and Github offers, which now come in handy almost every day. I now know how to create meaningful issues that follow the specifications of the project, as well as create and structure my Pull Requests to the standards of the project that I'm working on. Furthermore learning how to properly manipulate version history using ...
Read more