Part 1: Creating an open source Python project from scratch

Have you had a great idea for an open-source Python library that you think people will find useful, but you don’t know where to begin in creating and publishing it?

Part 2: Versioning and formatting your Python code

In this post, we will cover a few project hygiene things that we may want to put into place to make our lives easier in the future.

Part 3: Publishing open source Python packages on GitHub, PyPI and Conda Forge

In this post we will cover making our code available to people. This is the bit where we open the source! We will push our code to a code posting platform and then package up our library and submit it to a couple of repositories to make it easy for people to install.

Part 4: Documenting your Python code

This post will cover documenting our code. Specifically adding documentation within the code itself.

Docstrings

Right now our code is undocumented, so if the user inspects our function they will only see the interface (the way you call it) but with no other context. We can use IPython to quickly inspect this.

Part 5: Testing your Python package

In this post we will cover testing our code.

Testing

There are many many great resources out there for learning about testing software. In this post I’m going to try and focus on simple examples that you can use to get started quickly. Once you have a good foundation for your tests you can then dive into mocking, replaying HTTP requests or even hypothesis testing.

Part 6: Test driven development in Python

What is test driven development (TDD)?

Test driven development is a style of development where you write your tests before you write your code.

Part 7: Testing and Continuous Integration for Python packages with GitHub Actions

In this post we will cover automatically running our tests when we push new code to GitHub, and when contributors raise Pull Requests against our project.

Part 8: Automating releases of Python packages with GitHub Actions

In this post we will cover automatically packaging and releasing our project when a new git tag is pushed to GitHub.

Part 9: Documenting Python projects with Sphinx and Read the Docs

In part four of this series we discussed documenting our code as we went along by adding docstrings throughout out project. In this post we will see that effort pay off by building a documentation site using Sphinx which will leverage all of our existing docstrings.

Part 10: Building a user community for your open source project

Now that our open source Python project exists and users can install it we will want to turn our attention to sustainability, reach and ongoing maintenance. By putting it out there and gaining users you are opening yourself up to questions, bug reports and feature requests.

Part 11: Communicating with your open source community

Once your open source Python project has users and a community you will likely want to communicate with them in an official capacity. Perhaps you want to tell them about a new release, show a use case where someone is using your tool or solicit feedback on an upcoming feature.

Part 12: Building a contributor community for your open source project

With our open source project published on GitHub we probably want to allow folks to contribute changes. Some users of the project may find bugs, or desire extra features and will open issues to tell you. Users who have the skills required to make that change can open a Pull Request on GitHub to propose it. As the maintainer you can then review and merge those changes.

Part 13: Branding your open source Python package

Having a brand can help give your open source project some legitimacy, and you don’t need to be a designer to see these benefits. However it is important to understand that you do not need to add branding to your project in order for it to be successful, and adding branding can even harm your project.