PyScaffold comes with a lot of elaborated features and configuration defaults to make the most common tasks in developing, maintaining and distributing your own Python package as easy as possible.
Configuration & Packaging¶
All configuration can be done in
setup.cfg like changing the description,
url, classifiers and even console scripts of your project with the help of
pbr. That means in most
cases it is not necessary to tamper with
setup.py. The syntax of
setup.cfg is pretty much self-explanatory and well commented, check out
this example or pbr’s usage manual.
In order to build a source, binary or wheel distribution, just run
python setup.py sdist,
python setup.py bdist or
python setup.py bdist_wheel.
Optionally, namespace packages can be used, if you are planning to distribute a larger package as a collection of smaller ones. For example, use:
putup my_project --package my_package --with-namespace com.my_domain
my_package inside the namespace
com.my_domain in java-style.
Package and Files Data
Additional data, e.g. images and text files, inside your package can be
configured under the
[files] section in
setup.cfg. It is not necessary
to have a
MANIFEST.in file for this to work.
To read this data in your code, use:
from pkgutil import get_data data = get_data('my_package', 'path/to/my/data.txt')
Make sure that all files you specify in
[files] have been added to
Complete Git Integration¶
Your project is already an initialised Git repository and
the information of tags to infer the version of your project with the help of
To use this feature you need to tag with the format
python setup.py --version to retrieve the current PEP440-compliant version. This version
will be used when building a package and is also accessible through
Unleash the power of Git by using its pre-commit hooks. This feature is available through the
--with-pre-commit flag. After your project’s scaffold was generated, make
sure pre-commit is installed, e.g.
pip install pre-commit, then just run
It goes unsaid that also a default
.gitignore file is provided that is well
adjusted for Python projects and the most common tools.
Build the documentation with
python setup.py docs and run doctests with
python setup.py doctest. Start editing the file
extend the documentation. The documentation also works with Read the Docs.
The Numpy and Google style docstrings are activated by default. Just make sure Sphinx 1.3 or above is installed.
Unittest & Coverage¶
python setup.py test to run all unittests defined in the subfolder
tests with the help of py.test and
pytest-runner. Some sane
default flags for py.test are already defined in the
[pytest] section of
setup.cfg. The py.test plugin
pytest-cov is used to automatically
generate a coverage report. It is also possible to provide additional
parameters and flags on the commandline, e.g., type:
python setup.py test --addopts -h
to show the help of py.test.
JUnit and Coverage HTML/XML
For usage with a continuous integration software JUnit and Coverage XML output
can be activated in
setup.cfg. Use the flag
--with-travis to generate
templates of the Travis configuration files
tests/travis_install.sh which even features the
coverage and stats system Coveralls.
In order to use the virtualenv management and test tool Tox the flag
--with-tox can be specified.
Managing test environments with tox
tox to generate test virtual environments for various python
environments defined in the generated
tox.ini. Testing and building
sdists for python 2.7 and python 3.4 is just as simple with tox as:
tox -e py27,py34
Environments for tests with the the static code analyzers pyflakes and pep8 which are bundled in flake8 are included as well. Run it explicitly with:
tox -e flake8
With tox, you can use the
--recreate flag to force tox to create new
environments. By default, PyScaffold’s tox configuration will execute tests for
a variety of python versions. If an environment is not available on the system
the tests are skipped gracefully. You can relay on the tox documentation for detailed configuration options.
Management of Requirements & Licenses¶
Add the requirements of your project to
test-requirements.txt which will be automatically used by
This also allows you to easily customize a plain virtual environment with:
pip install -r requirements.txt -r test-requirements.txt
Only absolutely necessary requirements of your project shoulbe be stated in
requirements.txt while the requirements only used for development and
especially for running the unittests should go into
Since PyScaffold uses pbr it is also possible to define requirements depending
on your Python version. Use the environment
PBR_REQUIREMENTS_FILES to define a comma-separated list of
requirement files if you want to use non-default names and locations.
All licenses from choosealicense.com can be
easily selected with the help of the
Keep your project’s scaffold up-to-date by applying
putput --update my_project when a new version of PyScaffold was released.
An update will only overwrite files that are not often altered by users like
setup.py. To update all files use
An existing project that was not setup with PyScaffold can be converted with
putup --force existing_project. The force option is completely safe to use
since the git repository of the existing project is not touched!
Also check out if configuration options in
setup.cfg have changed.
If you are updating from a PyScaffold version before 2.0, you must
manually remove the files
MANIFEST.in. If you
are updating from a version prior to 2.2, you must remove