Welcome to the “py-generic-project” manual!¶
This is a Cookiecutter template that creates a basic Python Setuptools project, which can be later on augmented with various optional accessories. See the demo for getting a 1ˢᵗ impression on how this Cookiecutter template can be used, including screenshots of the terminal session.
If you have questions or need any other kind of help, please join the springerle-users Google group.
The resulting project uses
invoke for task automation, and
setuptools for building and
distributing the project. A provided
autoenv script takes care
of creating a fully boot-strapped
virtualenv – it can also be used
manually if you don’t want to install
setup.py script follows the DRY principle and tries to minimize
repetition of project metadata by loading it from other places (like the
__init__.py). Incidently, this makes the script almost
identical between different projects, and thus provides an easy update
experience later on. Usually, the only specific thing in it is the
docstring with the project’s name and license notice. This relies on
conventions, especially check out
src folder, for their double-underscore meta variables.
It is also importable (by using the usual
if __name__ == '__main__'
idiom), and exposes the project’s setup data in a
project dict. This
allows other tools to exploit the contained data assembling code, and
again supports the DRY principle. The
rituals package uses that to
provide Invoke tasks that work for any project, based on its project
Other integrated tools are
pylint for code quality checking,
pytest for testing support, and a Travis CI configuration. To ease
writing code that supports both Python 2 and Python 3, Jinja2’s
_compat module is available in the package, and fitting
__future__ imports are placed in every module. See
Porting to Python 3 Redux
for a pragmatic porting guide, based on actual experience.
- Using the “py-generic-project” Template
- Packaging Python Software
- Installing Python Software
- Writing Sphinx Documentation
- Software License