Skip to content
Python project template and best practices
Python Makefile
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
.circleci
.github/workflows
pyfoobar
test
.flake8
.gitignore
.travis.yml
CODE_OF_CONDUCT.md
CONTRIBUTING.md
LICENSE
Makefile
README.md
codecov.yml
setup.py

README.md

pyfoobar

CircleCI travis codecov Code style: black awesome PyPi Version GitHub stars PyPi downloads

A Python project template that highlights some best practices in Python packaging. Can be used as a GitHub template for your new Python project.

Best practices

  • The name of the git repo should be the PyPi name of the package should be what you you type as import mypackagename. That means no hyphens in package names!

  • Your package should be a one-trick pony. Nobody wants to install a huge toolbox if all they need is the image converter in it.

  • After import yourpackagename, people should be able to call yourpackagename.__version__ plus some other meta data. This helps with debugging.

  • Choose a license for your code and provide a LICENSE[.txt] in the root level of your package as well as a statement in your main README. choosealicense.com can help you make a decision.

  • Use linting and formatting, include those in your integration tests.

    • black is a formatter that I like because you cannot configure it -- black is black.
    • Good linters are flake8 and pylint.
    • isort sorts your imports alphabetically.
  • Once you have tests in order, make sure they are executed with every git push. Two popular CI services that run your tests are travis and circleci. This repository contains the config files for each of the two.

  • Make sure that nobody can push to master. On GitHub, go to Settings -> Branches -> Add rule and select Require status checks to pass before merging and Include administrators. Development happens in pull requests, this makes sure that nobody -- including yourself -- ever accidentally pushes something broken to master.

  • Use a tool for measuring test coverage. codecov is one, and the circleci config submits the data to it.

  • If you have CI set up, want to show test coverage, or advertise the availability on PyPi, do so using a badge at the top of your README. Check out shields.io for what's available.

  • Include contributing guidelines and a code of conduct (edit to add appropriate enforcement contacts or use a template) to help foster a community.

What you can do with this template

First run

find . -type f -print0 -name "*.py" -o -name Makefile -o -name "*.yml" | xargs -0 sed -i 's/pyfoobar/your-project-name/g'

and rename the folder pyfoobar to customize the name.

There is a simple Makefile that can help you with certain tasks:

  • Run make format to apply formatting.

  • Run make check to check formatting and style.

  • Run make publish to

    • tag your project on git (make tag)
    • upload your package to PyPi (make upload)

    After publishing, people can install your package with

    pip3 install --user pyfoobar
    

Testing

To run the pyfoobar unit tests, check out this repository and type

pytest

License

pyfoobar is published under the MIT license.

You can’t perform that action at this time.