How Masonite ships good code with DeepSource

Masonite is a modern and developer centric Python web framework with around 180K+ downloads, built with two important goals in mind — batteries included and an extremely extensible architecture.

Masonite is perfect for beginner developers getting into their first web applications as well as experienced devs that need to utilize the full potential of Masonite to get their applications done.

What are some challenges you faced in maintaining code quality of Masonite?

Masonite as an open-source Python framework project has a unique challenge. The unique challenge is that we need to be able to accept code from hundreds of different developers and be able to adhere to a set of standards that some developers may not even know to exist. These standards protect against things like code inconsistencies and security vulnerabilities but even future issues like hard to find bugs because of overridden variables names.

Masonite is in a unique position to be the backbone of major business applications, and businesses rely on Masonite to be stable and performant. Improvements to Masonite can lead to improvements for hundreds to thousands of sites on the Internet. We rely on good and maintainable code quality to help us reach these goals.

Lastly, Masonite is an open-source project so we do not yet have a large budget we can use for dedicated code reviews. Luckily we keep our pull requests to a manageable size in order to be able to fit our volunteer time to code reviews but sometimes it is hard to find the volunteer time to be able to review pull requests in a timely manner and keep our community engaged and happy.

Did adoption of DeepSource help? If yes, how?

After we installed DeepSource, I felt exponentially more confident in our pull requests. It's amazing how many small would-be-could-be issues you don’t normally catch. Since DeepSource fits right into GitHub status checks, I feel very confident merging a pull request when the DeepSource checks pass. After doing code reviews and checking for implementation details, I can rely on DeepSource to check a plethora of other things I no longer need to spend a lot of time on. Integrating DeepSource has been incredible.

Furthermore, reading over the issues that DeepSource finds with the code I, and Masonite maintainers generally, have even become better developers because we now know what to look for in our codebase when creating new features or fixing issues. We carry this knowledge throughout the community, to other businesses, and to other projects.

What kind/category of issues do you find most useful?

What I find the most useful are those really hard to spot problems like a variable name being overridden in the same scope or a variable in the local scope overriding the global scope. We generally keep our Python classes to a minimum but even when you have a file 500 lines long with 15+ imports, it is hard to remember all the global scopes of an import.

Additionally, we are in a unique position where people with 0% knowledge of the codebase need to push a small fix that I explain in detail on a GitHub issue. To get the community engaged with Masonite, we promote developers to contribute to the Masonite repository that has never contributing to open source projects before. These awesome individuals could know nothing about Masonite or even Python. So issues can easily be introduced to the framework if we are not careful in our code reviews and DeepSource helps alleviate that fear as it becomes a great tool in the toolbox.

How do you like the integration with GitHub?

There are a couple of things I really like about DeepSource’s integration with GitHub. The first is that it integrates seamlessly into GitHub’s status checks and takes literally seconds to run. DeepSource is always the first check to come back and I can see it quickly, review it and make changes in a minute or two.

The other thing I really love about DeepSource’s GitHub integration is that it is heavily customizable. DeepSource likes to catch all issues which are great but not all issues are real issues with the framework. For example, a framework does not really know which exceptions will be thrown so it needs a very broad exception catching rule which in any application is generally a bad idea. With DeepSource, we are able to customize these checks down to the file level and ignore these issues. Very quickly we are able to have an extremely powerful tool in our continuous integration process that is tailor-made to our application.

Anything else you would like to say?

DeepSource is one of those things that are so easy to integrate with and it sounds countless hours of time immediately but also saves countless potential time down the line with its ability to catch issues before they become issues.

Integrating with DeepSource is a no brainer and its one of those services that I think will be integrated into every repository no matter how big or small. I can’t wait to see DeepSource reach its full potential as people discover it more and more in the industry.

Joe can be found on Twitter @JoeMancusoDev. Check out masoniteproject.com.