Skip to content

Latest commit

 

History

History
307 lines (209 loc) · 8.36 KB

DEVELOPMENT.rst

File metadata and controls

307 lines (209 loc) · 8.36 KB

Development

Here are some pointers for hacking on bezier.

Adding Features

In order to add a feature to bezier:

  1. Discuss: File an issue to notify maintainers of the proposed changes (i.e. just sending a large PR with a finished feature may catch maintainers off guard)
  2. Add tests: The feature must work fully on the following CPython versions: 2.7, 3.4 and 3.5 on both UNIX and Windows. In addition, the feature should have 100% line coverage.
  3. Documentation: The feature must (should) be documented with helpful doctest examples wherever relevant.

Running Unit Tests

We recommend using tox to run unit tests:

$ tox -e py27
$ tox -e py34
$ tox -e py35

However, pytest can be used directly (though it won't manage dependencies):

$ python2.7 -m py.test tests/
$ python3.4 -m py.test tests/
$ python3.5 -m py.test tests/

Test Coverage

bezier has 100% line coverage. The coverage is checked on every build and uploaded to coveralls.io via the COVERALLS_REPO_TOKEN environment variable set in the CircleCI environment.

To run the coverage report locally:

$ tox -e cover
$ # OR
$ python -m py.test \
>  --cov=bezier \
>  --cov=tests \
>  tests/ \
>  functional_tests/

Slow Tests

To run unit tests without tests that have been (explicitly) marked slow, use the --ignore-slow flag:

$ python -m py.test tests/ --ignore-slow

These slow tests have been identified via:

$ python -m py.test tests/ --durations=10

and then marked with pytest.mark.skipif.

Functional Tests

Line coverage and unit tests are not entirely sufficient to test numerical software. As a result, there is a fairly large collection of functional tests for bezier.

These give a broad sampling of curve-curve intersection, surface-surface intersection and segment-box intersection problems to check both the accuracy (i.e. detecting all intersections) and the precision of the detected intersections.

To run the functional tests:

$ tox -e functional
$ # OR
$ python -m py.test functional_tests/

For example, the following curve-curve intersection is a functional test case:

image

and there is a curve-curve doc which captures most of the cases in the functional tests.

A surface-surface intersection functional test case:

image

a segment-box functional test case:

image

and a "locate point on surface" functional test case:

image

Coding Style

Code is PEP8 compliant and this is enforced with flake8 and pylint.

To check compliance:

$ tox -e lint

A few extensions and overrides have been specified in the pylintrc configuration for bezier.

Docstring Style

We require docstrings on all public objects and enforce this with our lint checks. The docstrings mostly follow PEP257 and are written in the Google style, e.g.

Args:
    path (str): The path of the file to wrap
    field_storage (FileStorage): The :class:`FileStorage` instance to wrap
    temporary (bool): Whether or not to delete the file when the File
       instance is destructed

Returns:
    BufferedFileStorage: A buffered writable file descriptor

In order to support these in Sphinx, we use the Napoleon extension. In addition, the sphinx-docstring-typing Sphinx extension is used to allow for type annotation for arguments and result (introduced in Python 3.5).

Documentation

The documentation is built with Sphinx and automatically updated on RTD every time a commit is pushed to master.

To build the documentation locally:

$ tox -e docs
$ # OR
$ ./scripts/build_docs.sh

Documentation Snippets

A large effort is made to provide useful snippets in documentation. To make sure these snippets are valid (and remain valid over time), doctest is used to check that the interpreter output in the snippets are valid.

To run the documentation tests:

$ tox -e doctest
$ # OR
$ NO_IMAGES=True sphinx-build -W \
>   -b doctest \
>   -d docs/build/doctrees \
>   docs \
>   docs/build/doctest

Documentation Images

Many images are included to illustrate the curves / surfaces / etc. under consideration and to display the result of the operation being described. To keep these images up-to-date with the doctest snippets, the images are created as doctest cleanup.

To regenerate the images:

$ tox -e docs-images
$ # OR
$ sphinx-build -W \
>   -b doctest \
>   -d docs/build/doctrees \
>   docs \
>   docs/build/doctest

The images in the Curve-Curve Intersection document and and this document are generated as part of the functional tests:

$ python functional_tests/test_curve_curve.py --save-plot
$ python functional_tests/test_segment_box.py --save-plot
$ python functional_tests/test_surface_locate.py --save-plot
$ python functional_tests/test_surface_surface.py --save-plot

Continuous Integration

Tests are run on CircleCI after every commit. To see which tests are run, see the in the CircleCI config.

Deploying New Versions

New versions are deployed to PyPI automatically every time a new tag is pushed. To allow twine to authenticate (which is needed to upload) the TWINE_USERNAME and TWINE_PASSWORD environment variables are set in the CircleCI environment.

Supported Python Versions

bezier explicitly supports:

Supported versions can be found in the tox.ini config.

Versioning

bezier follows semantic versioning.

It is currently in major version zero (0.y.z), which means that anything may change at any time and the public API should not be considered stable.