cookiecutter-pylibrary

Cookiecutter template for a Python library.

Notes:

• This is largely designed to address this blog post about packaging python libraries.
  • ... and it will save you from packaging pitfalls.
• There's a bare library using this template (if you're curious about the final result): https://github.com/ionelmc/python-nameless.
• If you have a web application (not a library) you might want to take a look at django-docker.

Features

This is an "all inclusive" sort of template.

• Choice of various licenses.
• Tox for managing test environments for Python 2.7, 3.7+, PyPy etc.
• Pytest or Nose for testing Python 2.7, 3.7+, PyPy etc.
• Optional support for creating a tests matrix out of dependencies and python versions.
• Travis-CI and AppVeyor for continuous testing.
• Coveralls or Codecov for coverage tracking (using Tox).
• Documentation with Sphinx, ready for ReadTheDocs.
• Configurations for:
  • isort
  • bumpversion (bump2version required)
• Support for C extensions (including coverage measurement for the C code). See c_extension_support.
• Packaging and code quality checks. This template comes with a tox environment (check) that will:
  • Check if your README.rst is valid.
  • Check if the MANIFEST.in has any issues.

Requirements

Projects using this template have these minimal dependencies:

• Cookiecutter - just for creating the project
• Tox - for running the tests
• Setuptools - for building the package, wheels etc. Now-days Setuptools is widely available, it shouldn't pose a problem :)

To get quickly started on a new system, just install setuptools and then install pip. That's the bare minimum to required install Tox and Cookiecutter. To install them, just run this in your shell or command prompt:

pip install tox cookiecutter

Usage and options

This template is more involved than the regular cookiecutter-pypackage.

First generate your project:

cookiecutter gh:ionelmc/cookiecutter-pylibrary

You will be asked for these fields:

"Ionel Cristian Maries"

"[email protected]"

"https://blog.ionelmc.ro"

"ionelmc"

"Nameless"

"github.com"

"python-nameless"

"nameless"

"nameless"

"An example package [...]"

"today"

"now"

"0.1.0"

"no"

"no"

"no"

"no"

"no"

"plain"

"nameless"

"BSD license"

"no"

"yes"

"no"

"no"

"no"

"yes"

"sphinx-rtd-theme"

"no"

"repo_name.readthedocs.io"

"yes"

"no"

Developing the project

To run all the tests, just run:

tox

To see all the tox environments:

tox -l

To only build the docs:

tox -e docs

To build and verify that the built package is proper and other code QA checks:

tox -e check

Releasing the project

Before releasing your package on PyPI you should have all the tox environments passing.

Version management

This template provides a basic bumpversion configuration. It's as simple as running:

• bumpversion patch to increase version from 1.0.0 to 1.0.1.
• bumpversion minor to increase version from 1.0.0 to 1.1.0.
• bumpversion major to increase version from 1.0.0 to 2.0.0.

You should read Semantic Versioning 2.0.0 before bumping versions.

Building and uploading

Before building dists make sure you got a clean build area:

rm -rf build
rm -rf src/*.egg-info

Note:

Dirty build or egg-info dirs can cause problems: missing or stale files in the resulting dist or strange and confusing errors. Avoid having them around.

Then you should check that you got no packaging issues:

tox -e check

And then you can build the sdist, and if possible, the bdist_wheel too:

python setup.py clean --all sdist bdist_wheel

To make a release of the project on PyPI, assuming you got some distributions in dist/, the most simple usage is:

twine upload --skip-existing dist/*.whl dist/*.gz dist/*.zip

In ZSH you can use this to upload everything in dist/ that ain't a linux-specific wheel (you may need setopt extended_glob):

twine upload --skip-existing dist/*.(whl|gz|zip)~dist/*linux*.whl

For making and uploading manylinux1 wheels you can use this contraption:

docker run --rm -itv $(pwd):/code quay.io/pypa/manylinux1_x86_64 bash -c 'set -eux; cd code; rm -rf wheelhouse; for variant in /opt/python/*; do rm -rf dist build *.egg-info && $variant/bin/python setup.py clean --all bdist_wheel; auditwheel repair dist/*.whl; done; rm -rf dist build *.egg-info'
twine upload --skip-existing wheelhouse/*.whl
docker run --rm -itv $(pwd):/code quay.io/pypa/manylinux1_i686 bash -c 'set -eux; cd code; rm -rf wheelhouse; for variant in /opt/python/*; do rm -rf dist build *.egg-info && $variant/bin/python setup.py clean --all bdist_wheel; auditwheel repair dist/*.whl; done; rm -rf dist build *.egg-info'
twine upload --skip-existing wheelhouse/*.whl

Note:

twine is a tool that you can use to securely upload your releases to PyPI. You can still use the old python setup.py register sdist bdist_wheel upload but it's not very secure - your PyPI password will be sent over plaintext.

Changelog

See CHANGELOG.rst.

Questions & answers

There's no Makefile?

Sorry, no Makefile yet. The Tox environments stand for whatever you'd have in a Makefile.

Why does tox.ini have a passenv = *?

Tox 2.0 changes the way it runs subprocesses - it no longer passes all the environment variables by default. This causes all sorts of problems if you want to run/use any of these with Tox: SSH Agents, Browsers (for Selenium), Appengine SDK, VC Compiler and so on.

cookiecutter-pylibrary errs on the side of convenience here. You can always remove passenv = * if you like the strictness.

Why is the version stored in several files (pkg/__init__.py, setup.py, docs/conf.py)?

We cannot use a metadata/version file [1] because this template is to be used with both distributions of packages (dirs with __init__.py) and modules (simple .py files that go straight in site-packages). There's no good place for that extra file if you're distributing modules.

But this isn't so bad - bumpversion manages the version string quite neatly.

Not Exactly What You Want?

No way, this is the best. 😜

If you have criticism or suggestions please open up an Issue or Pull Request.