.. _license-discussion:

Licenses

========

Matplotlib only uses BSD compatible code. If you bring in code from

another project make sure it has a PSF, BSD, MIT or compatible license

(see the Open Source Initiative `licenses page

<http://www.opensource.org/licenses>`_ for details on individual

licenses). If it doesn't, you may consider contacting the author and

asking them to relicense it. GPL and LGPL code are not acceptable in

the main code base, though we are considering an alternative way of

distributing L/GPL code through an separate channel, possibly a

toolkit. If you include code, make sure you include a copy of that

code's license in the license directory if the code's license requires

you to distribute the license with it. Non-BSD compatible licenses

are acceptable in matplotlib toolkits (eg basemap), but make sure you

clearly state the licenses you are using.

Why BSD compatible?

-------------------

The two dominant license variants in the wild are GPL-style and

BSD-style. There are countless other licenses that place specific

restrictions on code reuse, but there is an important difference to be

considered in the GPL and BSD variants. The best known and perhaps

most widely used license is the GPL, which in addition to granting you

full rights to the source code including redistribution, carries with

it an extra obligation. If you use GPL code in your own code, or link

with it, your product must be released under a GPL compatible

license. I.e., you are required to give the source code to other

people and give them the right to redistribute it as well. Many of the

most famous and widely used open source projects are released under

the GPL, including linux, gcc, emacs and sage.

The second major class are the BSD-style licenses (which includes MIT

and the python PSF license). These basically allow you to do whatever

you want with the code: ignore it, include it in your own open source

project, include it in your proprietary product, sell it,

whatever. python itself is released under a BSD compatible license, in

the sense that, quoting from the PSF license page::

There is no GPL-like "copyleft" restriction. Distributing

binary-only versions of Python, modified or not, is allowed. There

is no requirement to release any of your source code. You can also

write extension modules for Python and provide them only in binary

form.

Famous projects released under a BSD-style license in the permissive

sense of the last paragraph are the BSD operating system, python and

TeX.

There are several reasons why early matplotlib developers selected a

BSD compatible license. matplotlib is a python extension, and we

choose a license that was based on the python license (BSD

compatible). Also, we wanted to attract as many users and developers

as possible, and many software companies will not use GPL code in

software they plan to distribute, even those that are highly committed

to open source development, such as `enthought

<http://enthought.com>`_, out of legitimate concern that use of the

GPL will "infect" their code base by its viral nature. In effect, they

want to retain the right to release some proprietary code. Companies

and institutions who use matplotlib often make significant

contributions, because they have the resources to get a job done, even

a boring one. Two of the matplotlib backends (FLTK and WX) were

contributed by private companies. The final reason behind the

licensing choice is compatibility with the other python extensions for

scientific computing: ipython, numpy, scipy, the enthought tool suite

and python itself are all distributed under BSD compatible licenses.

.. _testing:

Testing

=======

Matplotlib has a testing infrastructure based on nose_, making it easy

to write new tests. The tests are in :mod:`matplotlib.tests`, and

customizations to the nose testing infrastructure are in

:mod:`matplotlib.testing`. (There is other old testing cruft around,

please ignore it while we consolidate our testing to these locations.)

.. _nose: http://somethingaboutorange.com/mrl/projects/nose/

Requirements

------------

The following software is required to run the tests:

- nose_, version 1.0 or later

- `Ghostscript <http://pages.cs.wisc.edu/~ghost/>`_ (to render PDF

files)

- `Inkscape <http://inkscape.org>`_ (to render SVG files)

Running the tests

-----------------

Running the tests is simple. Make sure you have nose installed and run

the script :file:`tests.py` in the root directory of the distribution.

The script can take any of the usual `nosetest arguments`_, such as

=================== ===========

``-v`` increase verbosity

``-d`` detailed error messages

``--with-coverage`` enable collecting coverage information

=================== ===========

To run a single test from the command line, you can provide a

dot-separated path to the module followed by the function separated by

a colon, eg. (this is assuming the test is installed)::

python tests.py matplotlib.tests.test_simplification:test_clipping

An alternative implementation that does not look at command line

arguments works from within Python::

import matplotlib

matplotlib.test()

.. _`nosetest arguments`: http://somethingaboutorange.com/mrl/projects/nose/1.0.0/usage.html

Running tests by any means other than `matplotlib.test()`

does not load the nose "knownfailureif" (Known failing tests) plugin,

causing known-failing tests to fail for real.

Writing a simple test

---------------------

Many elements of Matplotlib can be tested using standard tests. For

example, here is a test from :mod:`matplotlib.tests.test_basic`::

from nose.tools import assert_equal

def test_simple():

"""

very simple example test

"""

assert_equal(1+1,2)

Nose determines which functions are tests by searching for functions

beginning with "test" in their name.

If the test as side effects that need to be cleaned up, such as

creating figures using the pyplot interface, use the ``@cleanup``

decorator::

from matplotlib.testing.decorators import cleanup

@cleanup

def test_create_figure():

"""

very simple example test that creates a figure using pyplot.

"""

fig = figure()

...

Writing an image comparison test

--------------------------------

Writing an image based test is only slightly more difficult than a

simple test. The main consideration is that you must specify the

"baseline", or expected, images in the

:func:`~matplotlib.testing.decorators.image_comparison` decorator. For

example, this test generates a single image and automatically tests

it::

import numpy as np

import matplotlib

from matplotlib.testing.decorators import image_comparison

import matplotlib.pyplot as plt

@image_comparison(baseline_images=['spines_axes_positions'])

def test_spines_axes_positions():

# SF bug 2852168

fig = plt.figure()

x = np.linspace(0,2*np.pi,100)

y = 2*np.sin(x)

ax = fig.add_subplot(1,1,1)

ax.set_title('centered spines')

ax.plot(x,y)

ax.spines['right'].set_position(('axes',0.1))

ax.yaxis.set_ticks_position('right')

ax.spines['top'].set_position(('axes',0.25))

ax.xaxis.set_ticks_position('top')

ax.spines['left'].set_color('none')

ax.spines['bottom'].set_color('none')

The first time this test is run, there will be no baseline image to

compare against, so the test will fail. Copy the output images (in

this case `result_images/test_category/spines_axes_positions.*`) to

the `baseline_images` tree in the source directory (in this case

`lib/matplotlib/tests/baseline_images/test_category`) and put them

under source code revision control (with `git add`). When rerunning

the tests, they should now pass.

There are two optional keyword arguments to the `image_comparison`

decorator:

- `extensions`: If you only wish to test some of the image formats

(rather than the default `png`, `svg` and `pdf` formats), pass a

list of the extensions to test.

- `tol`: This is the image matching tolerance, the default `1e-3`.

If some variation is expected in the image between runs, this

value may be adjusted.

Known failing tests

-------------------

If you're writing a test, you may mark it as a known failing test with

the :func:`~matplotlib.testing.decorators.knownfailureif`

decorator. This allows the test to be added to the test suite and run

on the buildbots without causing undue alarm. For example, although

the following test will fail, it is an expected failure::

from nose.tools import assert_equal

from matplotlib.testing.decorators import knownfailureif

@knownfailureif(True)

def test_simple_fail():

'''very simple example test that should fail'''

assert_equal(1+1,3)

Note that the first argument to the

:func:`~matplotlib.testing.decorators.knownfailureif` decorator is a

fail condition, which can be a value such as True, False, or

'indeterminate', or may be a dynamically evaluated expression.

Creating a new module in matplotlib.tests

-----------------------------------------

We try to keep the tests categorized by the primary module they are

testing. For example, the tests related to the ``mathtext.py`` module

are in ``test_mathtext.py``.

Let's say you've added a new module named ``whizbang.py`` and you want

to add tests for it in ``matplotlib.tests.test_whizbang``. To add

this module to the list of default tests, append its name to

``default_test_modules`` in :file:`lib/matplotlib/__init__.py`.

Using tox

---------

`Tox <http://tox.testrun.org/>`_ is a tool for running tests against

multiple Python environments, including multiple versions of Python

(e.g.: 2.6, 2.7, 3.2, etc.) and even different Python implementations

altogether (e.g.: CPython, PyPy, Jython, etc.)

Testing all 4 versions of Python (2.6, 2.7, 3.1, and 3.2) requires

having four versions of Python installed on your system and on the

PATH. Depending on your operating system, you may want to use your

package manager (such as apt-get, yum or MacPorts) to do this, or use

`pythonbrew <https://github.com/utahta/pythonbrew>`_.

tox makes it easy to determine if your working copy introduced any

regressions before submitting a pull request. Here's how to use it:

.. code-block:: bash

$ pip install tox

$ tox

You can also run tox on a subset of environments:

.. code-block:: bash

$ tox -e py26,py27

Tox processes everything serially so it can take a long time to test

several environments. To speed it up, you might try using a new,

parallelized version of tox called ``detox``. Give this a try:

.. code-block:: bash

$ pip install -U -i http://pypi.testrun.org detox

$ detox

Tox is configured using a file called ``tox.ini``. You may need to

edit this file if you want to add new environments to test (e.g.:

``py33``) or if you want to tweak the dependencies or the way the

tests are run. For more info on the ``tox.ini`` file, see the `Tox

Configuration Specification

<http://tox.testrun.org/latest/config.html>`_.

Using Travis CI

---------------

`Travis CI <http://travis-ci.org/>`_ is a hosted CI system "in the

cloud".

Travis is configured to receive notifications of new commits to GitHub

repos (via GitHub "service hooks") and to run builds or tests when it

sees these new commits. It looks for a YAML file called

``.travis.yml`` in the root of the repository to see how to test the

project.

Travis CI is already enabled for the `main matplotlib GitHub

repository <https://github.com/matplotlib/matplotlib/>`_ -- for

example, see `its Travis page

<http://travis-ci.org/#!/matplotlib/matplotlib>`_.

If you want to enable Travis CI for your personal matplotlib GitHub

repo, simply enable the repo to use Travis CI in either the Travis CI

UI or the GitHub UI (Admin | Service Hooks). For details, see `the

Travis CI Getting Started page

<http://about.travis-ci.org/docs/user/getting-started/>`_. This

generally isn't necessary, since any pull request submitted against

the main matplotlib repository will be tested.

Once this is configured, you can see the Travis CI results at

http://travis-ci.org/#!/your_GitHub_user_name/matplotlib -- here's `an

example <http://travis-ci.org/#!/msabramo/matplotlib>`_.