Introduction

Packaging python software that has helped improve you or your team’s workflow can be very beneficial to the greater Python community; it makes your software more robust and can also improve your ability to use it in house. However, without the proper infrastructure in place, your python package will likely either break over time or be too difficult for other users to use efficiently.

Making your codebase public can also give you exposure to other great programmers working on similar problems; the more people using your code, the more likely it is to grow and improve. If you have ever helped beta test software for a colleague then you’ve seen first hand how quickly fresh eyes on a problem can accelerate development; the easier your software is for new users to try, and potentially integrate into their workflows, the more testers you get.

In order to make your software work in the long haul, and for a broad group of users, it is important to consider what it is meant to do, whether it achieves that goal, and if the code will be maintainable into the future. These three requirements can be addressed via three tools: unit testing, linting, and continuous integration. With these three tools you can ensure that your python packages will function into the future and are well positioned to have new users use them or build upon them.

In this post, I will start by discussing these tools, and what packages we have access to in python to leverage them. Then I will do a brief walkthrough going through the setup all of these services in your own GitHub repository.

#python-libraries #unit-testing #python #travis-ci #continuous-integration