Skip to content


Folders and files

Last commit message
Last commit date

Latest commit



34 Commits

Repository files navigation


An opinionated, minimal cookiecutter template for Python packages, and some guidelines for Python packaging.


pip install cookiecutter
git clone
cookiecutter cookiecutter-pypackage-minimal/

You should then change the classifiers in {{ package_name }}/ - it is assumed that the project will run on the latest versions of Python 2 and 3, so you should remove any classifiers that do not apply. The full list of PyPI classifiers can be found here.

Fill out the README, and - if necessary - choose a license for the project.


The decisions cookiecutter-pypackage-minimal makes should all be explained here.


  • README should use reStructuredText format This is the format used by most Python tools, is expected by setuptools, and can be used by Sphinx.
  • As few README files as possible Additional README files (AUTHORS, CHANGELOG, etc) should be left to the user to create when necessary.


  • MIT license by default This template provides you the classic MIT licence: it lets people do almost anything they want with your project, including to make and distribute closed source versions. If you choose another license, you also need to update the {{ package_name }}/ file: adjust the classifiers and license fields accordingly.
  • A license is a requirement Nowadays, people who want to use your library/application want to make sure they can do it legally. If your library is a private library, you can use a private license. In the {{ package_name }}/ file, set license="Proprietary", and choose 'License :: Other/Proprietary License' in the trove classifiers.

  • Use setuptools It's the standard packaging library for Python. distribute has merged back into setuptools, and distutils is less capable.
  • should not import anything from the package When installing from source, the user may not have the packages dependencies installed, and importing the package is likely to raise an ImportError.
  • should be the canonical source of package dependencies There is no reason to duplicate dependency specifiers (i.e. also using a requirements.txt file). See the testing section below for testing dependencies.


  • Use Tox to manage test environments Tox provides isolation, runs tests across multiple Python versions, and ensures the package can be installed.
  • Uses pytest as the default test runner This can be changed easily, though pytest is a easier, more powerful test library and runner than the standard library's unittest.
  • Define testing dependencies in tox.ini Avoid duplicating dependency definitions, and use tox.ini as the canonical description of how the unittests should be run.
  • tests directory should not be a package The tests directory should not be a Python package unless you want to define some fixtures. But the best practices are to use PyTest fixtures which provides a better solution. Therefore, the tests directory has no file.


A minimal template for python packages







No releases published


No packages published