General Guidelines

sparse is a community-driven project on GitHub. You can find our repository on GitHub. Feel free to open issues for new features or bugs, or open a pull request to fix a bug or add a new feature.

If you haven’t contributed to open-source before, we recommend you read this excellent guide by GitHub on how to contribute to open source. The guide is long, so you can gloss over things you’re familiar with.

If you’re not already familiar with it, we follow the fork and pull model on GitHub.

Filing Issues

If you find a bug or would like a new feature, you might want to consider filing a new issue on GitHub. Before you open a new issue, please make sure of the following:

  • This should go without saying, but make sure what you are requesting is within the scope of this project.
  • The bug/feature is still present/missing on the master branch on GitHub.
  • A similar issue or pull request isn’t already open. If one already is, it’s better to contribute to the discussion there.

Contributing Code

This project has a number of requirements for all code contributed.

  • We use flake8 to automatically lint the code and maintain code style.
  • We use Numpy-style docstrings.
  • It’s ideal if user-facing API changes or new features have documentation added.
  • 100% code coverage is recommended for all new code in any submitted PR. Doctests count toward coverage.
  • Performance optimizations should have benchmarks added in benchmarks.

Setting up Your Development Environment

The following bash script is all you need to set up your development environment, after forking and cloning the repository:

pip install -e .[all]

Running/Adding Unit Tests

It is best if all new functionality and/or bug fixes have unit tests added with each use-case.

Since we support both Python 2.7 and Python 3.5 and newer, it is recommended to test with at least these two versions before committing your code or opening a pull request. We use pytest as our unit testing framework, with the pytest-cov extension to check code coverage and pytest-flake8 to check code style. You don’t need to configure these extensions yourself. Once you’ve configured your environment, you can just cd to the root of your repository and run


This automatically checks code style and functionality, and prints code coverage, even though it doesn’t fail on low coverage.


The pytest script automatically reports coverage, both on the terminal for missing line numbers, and in annotated HTML form in htmlcov/index.html.

Adding/Building the Documentation

If a feature is stable and relatively finalized, it is time to add it to the documentation. If you are adding any private/public functions, it is best to add docstrings, to aid in reviewing code and also for the API reference.

We use Numpy style docstrings and Sphinx to document this library. Sphinx, in turn, uses reStructuredText as its markup language for adding code.

We use the Sphinx Autosummary extension to generate API references. In particular, you may want do look at the docs/generated directory to see how these files look and where to add new functions, classes or modules. For example, if you add a new function to the sparse.COO class, you would open up docs/generated/sparse.COO.rst, and add in the name of the function where appropriate.

To build the documentation, you can cd into the docs directory and run

sphinx-build -b html . _build/html

After this, you can find an HTML version of the documentation in docs/_build/html/index.html.

Adding and Running Benchmarks

We use Airspeed Velocity to run benchmarks. We have it set up to use conda, but you can edit the configuration locally if you so wish.