Open Stack

Do we have anyone willing to spend some time looking at the
incompatibilities Ned mentions below to ensure that we have a smooth
transition when 4.0 moves out of alpha?

Doug

--- Begin forwarded message from Ned Batchelder ---
From: Ned Batchelder <ned at nedbatchelder.com>
To: testing-in-python <testing-in-python at lists.idyll.org>
Date: Mon, 03 Aug 2015 07:22:30 -0400
Subject: [TIP] Coverage.py 4.0 beta 1

Hi all,

After more than 18 months of development, the first beta of Coverage.py 
4.0 is available: https://pypi.python.org/pypi/coverage/4.0b1

There are a number of very significant changes since v3.7.1, including 
backward-incompatibilities.  I'd really appreciate getting some testing 
from people using third-party coverage integrations, or using unusual 
configurations.

Bug reports heartily welcomed: https://bitbucket.org/ned/coveragepy

A quick list of the biggest changes are below, more at 
http://coverage.readthedocs.org/en/coverage-4.0b1/changes.html

Thanks,

--Ned.



Backward incompatibilities:

- CPython versions supported are now Python 2.6, 2.7, 3.3, 3.4 and 3.5b4.
   PyPy2 2.4, 2.6, and PyPy3 2.4 are also supported.

- The original command line switches (`-x` to run a program, etc) are no
   longer supported.

- The ``COVERAGE_OPTIONS`` environment variable is no longer supported.  
It was
   a hack for ``--timid`` before configuration files were available.

- The original module-level function interface to coverage.py is no longer
   supported.  You must now create a ``coverage.Coverage`` object, and use
   methods on it.

- The ``Coverage.use_cache`` method is no longer supported.

- The private method ``Coverage._harvest_data`` is now called
   ``Coverage.get_data``, and returns the ``CoverageData`` containing the
   collected data.

- Coverage.py is now licensed under the Apache 2.0 license. See 
NOTICE.txt for
   details.


Major new features:

- Plugins: third parties can write plugins to add file support for 
non-Python
   files, such as web application templating engines, or languages that 
compile
   down to Python.  A plugin for measuring Django template coverage is
   available: `django_coverage_plugin`_

- The data storage has been re-written, using JSON instead of pickle.  The
   :class:`CoverageData` class is a new supported API to the contents of the
   data file.

- Gevent, eventlet, and greenlet are now supported, closing `issue 
149`_.  The
   ``concurrency`` setting, or the ``--concurrency`` command line switch,
   specifies the concurrency library in use.  Huge thanks to Peter 
Portante for
   initial implementation, and to Joe Jevnik for the final insight that
   completed the work.

- Wildly experimental: support for measuring processes started by the
   multiprocessing module.  To use, set ``--concurrency=multiprocessing``,
   either on the command line or in the .coveragerc file (`issue 117`_). 
Thanks,
   Eduardo Schettino.  Currently, this does not work on Windows.


New features:

- Options are now also read from a setup.cfg file, if any.  Sections are
   prefixed with "coverage:", so the ``[run]`` options will be read from the
   ``[coverage:run]`` section of setup.cfg.  Finishes `issue 304`_.

- A new option: `coverage report --skip-covered` (or ``[report] 
skip_covered``)
   will reduce the number of files reported by skipping files with 100%
   coverage.  Thanks, Krystian Kichewko.  This means that empty 
`__init__.py`
   files will be skipped, since they are 100% covered, closing `issue 315`_.

- You can now specify the ``--fail-under`` option in the ``.coveragerc`` 
file
   as the ``[report] fail_under`` options.  This closes `issue 314`_.

- The ``report`` command can now show missing branches when reporting on 
branch
   coverage.  Thanks, Steve Leonard. Closes `issue 230`_.

- The ``coverage combine`` command now accepts any number of directories or
   files as arguments, and will combine all the data from them.  This 
means you
   don't have to copy the files to one directory before combining. Thanks,
   Christine Lytwynec.  Finishes `issue 354`_.

- A new configuration option for the XML report: ``[xml] package_depth``
   controls which directories are identified as packages in the report.
   Directories deeper than this depth are not reported as packages.
   The default is that all directories are reported as packages.
   Thanks, Lex Berezhny.

- A new configuration option, ``[run] note``, lets you set a note that 
will be
   stored in the `runs` section of the data file.  You can use this to 
annotate
   the data file with any information you like.

- The COVERAGE_DEBUG environment variable can be used to set the ``[run] 
debug``
   configuration option to control what internal operations are logged.

--- End forwarded message ---