Cookiecutter template for a Python package.
- pytest! Uses
pytest
with asetup.py
test command. See:python setup.py test
andmake test
- git-flow friendly! Subtle changes to improve git-flow workflow.
- coveralls! Preconfigured integration with coveralls--coverage report monitoring.
- pip-tools! Uses pip-tools for managing dependendencies. See:
make requirements
. - Better requirements management. Project and dev requirements are seperated, and pip-tools makes it easier to update and pin requirements.
- PyPy! Preconfigured to include PyPy. This is usually free accessibility! Try it out! See if PyPy passes your tests.
- Better Tox + Travis-CI setup. Philosophy: Tox should do the maximum amount of work, and Travis-CI the minimum. This creates a more consistent results when testing locally vs remotely on Travis-CI.
- Inludes
_compat
module andlogging
boilerplate.
Github readme is automatically generated from compiling doc sources, reasoning:
- Sphinx specific RST doesn't render on github (ugly) and outright breaks PyPI. For example, if you use Sphinx' python domain references, it looks like this:
MyAwesomeClass
or :pyMyAwesomeClass
instead ofMyAwesomeClass
- Usually you want to include extra sections on the github README. For example, I like to include installation instructions and a quick start guide. But I also like how things look on ReadTheDocs, and don't want to mess that up. The answer is they need to be combined using a different process. This fork delivers a DRY and intuitive process to have both.
See:
make github
anddocs/github_docs.py
. I wrote a minimalistic, text processing framework--it should be intuitive to extend and customize for your needs.- Sphinx specific RST doesn't render on github (ugly) and outright breaks PyPI. For example, if you use Sphinx' python domain references, it looks like this:
- Doc sources follow the nested format, adding clarity.
- Includes a doc linter to avoid PyPI's RST parser from breaking.
A million times more badges, badges for everything! You get a badge, you get badge, and YOU get badge!!
- Open source MIT license
- Travis-CI: Ready for Travis Continuous Integration testing
- Tox testing: Setup to easily test for Python 2.6, 2.7, 3.3, 3.4, 3.5, and PyPy
- Sphinx docs: Documentation ready for generation with, for example, ReadTheDocs
- Bumpversion: Pre-configured version bumping with a single command
- Auto-release to PyPI when you push a new tag to master (optional)
Generate a Python package project:
cookiecutter https://github.com/bionikspoon/cookiecutter-pypackage
Then:
- Create a repo and put it there.
- Add the repo to your Travis CI account.
- Install the dev requirements into a virtualenv. (
pip install -r requirements_dev.txt
) - Run the script travis_pypi_setup.py to encrypt your PyPI password in Travis config and activate automated deployment on PyPI when you push a new tag to master branch.
- Add the repo to your ReadTheDocs account + turn on the ReadTheDocs service hook.
- Release your package by pushing a new tag to master.
- (Optional) If you feel like pinning the requirements for your package, you can add a requirements.txt that specifies packages and version numbers.
For more details, see the cookiecutter-pypackage tutorial.
Don't worry, you have options:
- Nekroze/cookiecutter-pypackage: A fork of this with a PyTest test runner, strict flake8 checking with Travis/Tox, and some docs and setup.py differences.
- tony/cookiecutter-pypackage-pythonic: Fork with py2.7+3.3 optimizations. Flask/Werkzeug-style test runner,
_compat
module and module/doc conventions. SeeREADME.rst
or the github comparison view for exhaustive list of additions and modifications. - ardydedase/cookiecutter-pypackage: A fork with separate requirements files rather than a requirements list in the
setup.py
file. - Also see the network and family tree for this repo. (If you find anything that should be listed here, please add it and send a pull request!)
If you have differences in your preferred setup, I encourage you to fork this to create your own version. Or create your own; it doesn't strictly have to be a fork.
- Once you have your own version working, add it to the Similar Cookiecutter Templates list above with a brief description.
- It's up to you whether or not to rename your fork/own version. Do whatever you think sounds good.
I also accept pull requests on this, if they're small, atomic, and if they make my own packaging experience better.