Commit 97996da2 authored by SVN-Git Migration's avatar SVN-Git Migration

Imported Upstream version 0.7.0

parents
Copyright (c) 2014, Jeff Forcier
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
include LICENSE
include dev-requirements.txt
include tasks.py
recursive-include docs *
recursive-exclude docs/_build *
recursive-include tests *
recursive-exclude tests *.pyc *.pyo
Metadata-Version: 1.0
Name: releases
Version: 0.7.0
Summary: A Sphinx extension for changelog manipulation
Home-page: https://github.com/bitprophet/releases
Author: Jeff Forcier
Author-email: jeff@bitprophet.org
License: UNKNOWN
Description: UNKNOWN
Platform: UNKNOWN
Classifier: Intended Audience :: Developers
Classifier: License :: OSI Approved :: BSD License
Classifier: Operating System :: MacOS :: MacOS X
Classifier: Operating System :: Unix
Classifier: Operating System :: POSIX
Classifier: Programming Language :: Python
Classifier: Programming Language :: Python :: 2.6
Classifier: Programming Language :: Python :: 2.7
Classifier: Programming Language :: Python :: 3.2
Classifier: Programming Language :: Python :: 3.3
Classifier: Topic :: Software Development
Classifier: Topic :: Software Development :: Build Tools
Classifier: Topic :: Software Development :: Libraries
Classifier: Topic :: Software Development :: Libraries :: Python Modules
.. image:: https://secure.travis-ci.org/bitprophet/releases.png?branch=master
:target: https://travis-ci.org/bitprophet/releases
What is Releases?
=================
Releases is a `Sphinx <http://sphinx-doc.org>`_ extension designed to help you
keep a source control friendly, merge friendly changelog file & turn it into
useful, human readable HTML output.
Specifically:
* The source format (kept in your Sphinx tree as ``changelog.rst``) is a
stream-like timeline that plays well with source control & only requires one
entry per change (even for changes that exist in multiple release lines).
* The output (when you have the extension installed and run your Sphinx build
command) is a traditional looking changelog page with a section for every
release; multi-release issues are copied automatically into each release.
* By default, feature and support issues are only displayed under feature
releases, and bugs are only displayed under bugfix releases. This can be
overridden on a per-issue basis.
Some background on why this tool was created can be found in `this blog post
<http://bitprophet.org/blog/2013/09/14/a-better-changelog/>`_.
For more documentation, including detailed installation and usage information,
please see http://releases.readthedocs.org.
.. note::
You can install the `development version
<https://github.com/bitprophet/releases/tarball/master#egg=releases-dev>`_
via ``pip install releases==dev``.
# Task runner
invoke>=0.6.0
invocations>=0.4.1
# Tests (N.B. integration suite also uses Invoke as above)
spec>=0.11.1
mock==1.0.1
# Just for tests...heh
six>=1.4.1
# Docs
-e .
sphinx>=1.1
sphinx_rtd_theme>=0.1.5
=========
Changelog
=========
* :release:`0.7.0 <2014-09-04>`
* :bug:`30 major` Add LICENSE (plus a handful of other administrative files) to
a ``MANIFEST.in`` so sdists pick it up. Thanks to Zygmunt Krynicki for catch
& original patch (:issue:`33`).
* :feature:`21` Allow duplicate issue numbers; not allowing them was
technically an implementation detail. Thanks to Dorian Puła for the patch.
* :release:`0.6.1 <2014-04-06>`
* :bug:`-` Fix a silly issue with the new feature from :issue:`22` where it
accidentally referred to the Sphinx document *title* instead of the document
*filename*.
* :release:`0.6.0 <2014-04-03>`
* :feature:`22` Make the document name used as the changelog - previously
hardcoded as ``changelog`` (``.rst``) - configurable. Thanks to James Mills
for the feature request.
* :feature:`26` Allow specifying Github path shorthand config option instead of
explicit release/issue URL strings.
* :release:`0.5.3 <2014-03-15>`
* :bug:`25` Empty/no-issue line items broke at some point; fixed.
* :bug:`24` Broke inline issue parsing; fixed now.
* :release:`0.5.2 <2014-03-13>`
* :bug:`23` Rework implementation to deal with issue descriptions that span
more than one paragraph - subsequent paragraphs/blocks were not being
displayed prior.
* :release:`0.5.1 <2014-02-11>`
* :bug:`-` Fix silly bug in :issue:`20` that cropped up on Python 3.x.
* :release:`0.5.0 <2014-02-11>`
* :feature:`20` Allow specifying minimum release line in bugfixes that don't
apply to all active lines (e.g. because they pertain to a recently added
feature.)
* :release:`0.4.0 <2013-12-24>`
* :feature:`17` Allow releases to explicitly define which issues they include.
Useful for overriding default assumptions (e.g. a special bugfix release from
an otherwise dormant line.)
* :release:`0.3.1 <2013-12-18>`
* :bug:`16` Fix some edge cases regarding release ordering & unreleased issue
display. Includes splitting unreleased display info into two 'Next release'
pseudo-release entries.
* :support:`15` Add :doc:`/concepts` to flesh out some assumptions not
adequately explained in :doc:`/usage`.
* :release:`0.3.0 <2013-11-21>`
* :feature:`11` Fix up styling so changelogs don't look suboptimal under `the
new Read The Docs theme
<http://ericholscher.com/blog/2013/nov/4/new-theme-read-the-docs/>`_. Still
looks OK under their old theme too!
* :support:`0` Move to actual Sphinx docs so we can use ourselves.
* :support:`0` Created a basic test suite to protect against regressions.
* :bug:`9 major` Clean up additional 'unreleased' display/organization
behavior, including making sure ALL unreleased issues show up as
'unreleased'. Thanks to Donald Stufft for the report.
* :feature:`1` (also :issue:`3`, :issue:`10`) Allow using ``-`` or ``0`` as a
dummy issue 'number', which will result in no issue number/link being
displayed. Thanks to Markus Zapke-Gründemann and Hynek Schlawack for patches
& discussion.
* This feature lets you categorize changes that aren't directly related
to issues in your tracker. It's an improvement over, and replacement
for, the previous "vanilla bullet list items are treated as bugs"
behavior.
* Said behavior (non-role-prefixed bullet list items turning into
regular bugs) is being retained as there's not a lot to gain from
deactivating it.
* :release:`0.2.4 <2013.10.04>`
* :support:`0 backported` Handful of typos, doc tweaks & addition of a
.gitignore file. Thanks to Markus Zapke-Gründemann.
* :bug:`0` Fix duplicate display of "bare" (not prefixed with an issue role)
changelog entries. Thanks again to Markus.
* :support:`0 backported` Edited the README/docs to be clearer about how
Releases works/operates.
* :support:`0 backported` Explicitly documented how non-role-prefixed line
items are preserved.
* :bug:`0` Updated non-role-prefixed line items so they get prefixed with a
'[Bug]' signifier (since they are otherwise treated as bugfix items.)
* :release:`0.2.3 <2013.09.16>`
* :bug:`0` Fix a handful of bugs in release assignment logic.
* :release:`0.2.2 <2013.09.15>`
* :bug:`0` Ensured Python 3 compatibility.
* :release:`0.2.1 <2013.09.15>`
* :bug:`0` Fixed a stupid bug causing invalid issue hyperlinks.
* :release:`0.2.0 <2013.09.15>`
* :feature:`0` Basic functionality.
========
Concepts
========
Basic conceptual info about how Releases organizes and thinks about issues and
releases. For details on formatting/etc (e.g. so you can interpret the examples
below), see :doc:`/usage`.
Issue and release types
=======================
* Issues are always one of three types: **features**, **bug fixes** or
**support items**.
* **Features** are (typically larger) changes adding new behavior.
* **Bug fixes** are (typically minor) changes addressing incorrect
behavior, crashes, etc.
* **Support items** vary in size but are usually non-code-related changes,
such as documentation or packaging updates.
* Releases also happen to come in three flavors:
* **Major releases** are backwards incompatible releases, often with
large/sweeping changes to a codebase.
* They increment the first version number only, e.g. ``1.0.0``.
* **Feature releases** (sometimes called **minor** or **secondary**) are
backwards compatible with the previous major release, and focus on adding
new functionality (code, or support, or both.) They sometimes include
major/complex bug fixes which are too risky to include in a bugfix
release.
* The second version number is incremented for these, e.g. ``1.1.0``.
* **Bugfix releases** (sometimes called **tertiary**) focus on fixing
incorrect behavior while minimizing the risk of creating more bugs.
Rarely, they will include small new features deemed important enough to
backport from their 'native' feature release.
* These releases increment the third/final version number, e.g.
``1.1.1``.
Release organization
====================
We parse changelog timelines so the resulting per-release issue lists honor the
above descriptions. Here are the core rules, with examples. See :doc:`/usage`
for details on formatting/etc.
* **By default, bugfixes go into bugfix releases, features and support items go
into feature releases.**
* Input::
* :release:`1.1.0 <date>`
* :release:`1.0.1 <date>`
* :support:`4` Updated our test runner
* :bug:`3` Another bugfix
* :feature:`2` Implemented new feature
* :bug:`1` Fixed a bug
* :release:`1.0.0 <date>`
* Result:
* ``1.0.1``: bug #1, bug #3
* ``1.1.0``: feature #2, support #4
* **Bugfixes are assumed to backport to all stable release lines by default,
and are displayed as such.** However, this can be overridden on a per-release
and/or per-bug basis - see later bullet points.
* Input::
* :release:`1.1.1 <date>`
* :release:`1.0.2 <date>`
* :bug:`3` Fixed another bug, onoes
* :release:`1.1.0 <date>`
* :release:`1.0.1 <date>`
* :feature:`2` Implemented new feature
* :bug:`1` Fixed a bug
* :release:`1.0.0 <date>`
* Result:
* ``1.0.1``: bug #1
* ``1.1.0``: feature #2
* ``1.0.2``: bug #3
* ``1.1.1``: bug #3
* **Bugfixes marked 'major' go into feature releases instead.**
* Input::
* :release:`1.1.0 <date>`
* :release:`1.0.1 <date>`
* :bug:`3 major` Big bugfix with lots of changes
* :feature:`2` Implemented new feature
* :bug:`1` Fixed a bug
* :release:`1.0.0 <date>`
* Result:
* ``1.0.1``: bug #1
* ``1.1.0``: feature #2, bug #3
* **Features or support items marked 'backported' appear in both bugfix and
feature releases.**
* Input::
* :release:`1.1.0 <date>`
* :release:`1.0.1 <date>`
* :bug:`4` Fixed another bug
* :feature:`3` Regular feature
* :feature:`2 backported` Small new feature worth backporting
* :bug:`1` Fixed a bug
* :release:`1.0.0 <date>`
* Result:
* ``1.0.1``: bug #1, feature #2, bug #4
* ``1.1.0``: feature #2, feature #3
* **Releases implicitly include all issues from their own, and prior, release
lines.** (Again, unless the release explicitly states otherwise - see below.)
* For example, in the below changelog (remembering that changelogs are
written in descending order from newest to oldest entry) the code
released as ``1.1.0`` includes the changes from bugs #1 and #3, in
addition to its explicitly stated contents of feature #2::
* :release:`1.1.0 <date>`
* :release:`1.0.1 <date>`
* :bug:`3` Another bugfix
* :feature:`2` Implemented new feature
* :bug:`1` Fixed a bug
* :release:`1.0.0 <date>`
* Again, to be explicit, the rendered changelog displays this breakdown:
* ``1.0.1``: bug #1, bug #3
* ``1.1.0``: feature #2
But it's *implied* that ``1.1.0`` includes the contents of ``1.0.1``
because it released afterwards/simultaneously and is a higher release
line.
* **Releases may be told explicitly which issues to include** (using a
comma-separated list.) This is useful for the rare bugfix that gets
backported beyond the actively supported release lines.
For example, below shows a project whose lifecycle is "release 1.0; release
1.1 and drop active support for 1.0; put out a special 1.0.x release."
Without the explicit issue list for 1.0.1, Releases would roll up all
bugfixes, including the two that didn't actually apply to the 1.0 line.
* Input::
* :release:`1.0.1 <date>` 1, 5
* :release:`1.1.1 <date>`
* :bug:`5` Bugfix that applied back to 1.0.
* :bug:`4` Bugfix that didn't apply to 1.0, only 1.1
* :bug:`3` Bugfix that didn't apply to 1.0, only 1.1
* :release:`1.1.0 <date>`
* :feature:`2` Implemented new feature
* :bug:`1` Fixed a 1.0.0 bug
* :release:`1.0.0 <date>`
* Result:
* ``1.1.0``: feature #2
* ``1.1.1``: bugs #3, #4 and #5
* ``1.0.1``: bugs #1 and #5 only
* **Bugfix issues may be told explicitly which release line they 'start' in.**
This is useful for bugs that don't go back all the way to the oldest actively
supported line - it keeps them from showing up in "too-old" releases.
The below example includes a project actively supporting 1.5, 1.6 and 1.7
release lines, with a couple of bugfixes that only applied to 1.6+.
* Input::
* :release:`1.7.1 <date>`
* :release:`1.6.2 <date>`
* :release:`1.5.3 <date>`
* :bug:`50` Bug applying to all lines
* :bug:`42 (1.6+)` A bug only applying to the new feature in 1.6
* :release:`1.7.0 <date>`
* :release:`1.6.1 <date>`
* :release:`1.5.2 <date>`
* :feature:`25` Another new feature
* :bug:`35` Bug that applies to all lines
* :bug:`34` Bug that applies to all lines
* :release:`1.6.0 <date>`
* :release:`1.5.1 <date>`
* :feature:`22` Some new feature
* :bug:`20` Bugfix
* :release:`1.5.0 <date>`
* Result:
* ``1.5.1``: bug #20
* ``1.6.0``: feature #22
* ``1.5.2``: bugs #34, #35
* ``1.6.1``: bugs #34, #35
* ``1.7.0``: feature #25
* ``1.5.3``: bug #50 only
* ``1.6.2``: bugs #50 and #42
* ``1.7.1``: bugs #50 and #42
from datetime import datetime
import os
import sys
import sphinx_rtd_theme
extensions = []
templates_path = ['_templates']
source_suffix = '.rst'
master_doc = 'index'
project = u'Releases'
year = datetime.now().year
copyright = u'%d Jeff Forcier' % year
# Ensure project directory is on PYTHONPATH for version, autodoc access
sys.path.insert(0, os.path.abspath(os.path.join(os.getcwd(), '..')))
exclude_patterns = ['_build']
# RTD theme
html_theme = "sphinx_rtd_theme"
html_theme_path = [sphinx_rtd_theme.get_html_theme_path()]
# Dogfood
extensions.append('releases')
releases_github_path = 'bitprophet/releases'
========
Releases
========
.. include:: ../README.rst
Table of Contents
=================
.. toctree::
:maxdepth: 2
concepts
usage
changelog
todo
====
TODO
====
* Possibly add more keywords to allow control over additional edge cases.
* Add shortcut format option for the release/issue URI settings - GitHub users
can just give their GitHub acct/repo and we will fill in the rest.
* Maybe say pre-1.0 releases consider all bugs 'major' (so one can e.g. put out
an 0.4.0 which is all bugfixes). Iffy because what if you *wanted* regular
feature-vs-bugfix releases pre-1.0? (which is common.)
* Make sure regular ``:issue:`` is documented.
=====
Usage
=====
To use Releases, mimic the format seen in `its own changelog
<https://raw.github.com/bitprophet/releases/master/docs/changelog.rst>`_ or in
`Fabric's changelog
<https://raw.github.com/fabric/fabric/master/docs/changelog.rst>`_.
Specifically:
* Install ``releases`` and update your Sphinx ``conf.py`` to include it in the
``extensions`` list setting: ``extensions = ['releases']``.
* Also set the ``releases_release_uri`` and ``releases_issue_uri`` top
level options - they determine the targets of the issue & release links
in the HTML output. Both should have an unevaluated ``%s`` where the
release/issue number would go.
* Alternately, if your project is hosted on Github, set the
``releases_github_path`` setting instead, to e.g.
``account/project``. Releases will then use an appropriate Github
URL for both releases and issues.
* If ``releases_release_uri`` or ``releases_issue_uri`` are *also*
configured, they will be preferred over ``releases_github_path``.
(If only one is configured, the other link type will continue using
``releases_github_path``.)
* See `Fabric's docs/conf.py
<https://github.com/fabric/fabric/blob/4afd33e971f1c6831cc33fd3228013f7484fbe35/docs/conf.py#L31>`_
for an example.
* You may optionally set ``releases_debug = True`` to see debug output
while building your docs.
* Create a Sphinx document named ``changelog.rst`` with a top-level header
followed by a bulleted list.
* If you wish to use a different document name, use another config option
(as per previous bullet point), ``releases_document_name``. E.g.
``releases_document_name = "CHANGES"`` would cause Releases to mutate a
file called ``CHANGES.rst`` instead of ``changelog.rst``.
* List items are to be ordered chronologically with the newest ones on top.
* As you fix issues, put them on the top of the list.
* As you cut releases, put those on the top of the list and they will
include the issues below them.
* Issues with no releases above them will end up in a specially marked
"Unreleased" section of the rendered changelog.
* Bullet list items should use the ``support``, ``feature`` or ``bug``
roles to mark issues, or ``release`` to mark a release. These special roles
must be the first element in each list item.
* Line-items that do not start with any issue role will be considered bugs
(both in terms of inclusion in releases, and formatting) and, naturally,
will not be given a hyperlink.
* Issue roles are of the form ``:type:`number[ keyword]```. Specifically:
* ``number`` is used to generate the link to the actual issue in your issue
tracker (going by the ``releases_issue_uri`` option). It's used for both
the link target & (part of) the link text.
* If ``number`` is given as ``-`` or ``0`` (as opposed to a "real" issue
number), no issue link will be generated. You can use this for items
without a related issue.
* Keywords are optional and may be one of:
* ``backported``: Given on *support* or *feature* issues to denote
backporting to bugfix releases; such issues will show up in both
release types. E.g. placing ``:support:`123 backported``` in your
changelog below releases '1.1.1' and '1.2.0' will cause it to appear
in both of those releases' lists.
* ``major``: Given on *bug* issues to denote inclusion in feature,
instead of bugfix, releases. E.g. placing ``:bug:`22 major``` below
releases '1.1.1' and '1.2.0' will cause it to appear in '1.2.0'
**only**.
* ``(N.N+)`` where ``N.N`` is a valid release line, e.g. ``1.1`` or
``2.10``: Given on *bug* issues to denote minimum release line. E.g.
when actively backporting most bugs to release lines 1.2, 1.3 and
1.4, you might specify ``:bug:`55 (1.3+)``` to note that bug 55 only
applies to releases in 1.3 and above - not 1.2.
* Regular Sphinx content may be given after issue roles and will be preserved
as-is when rendering. For example, in ``:bug:`123` Fixed a bug, thanks
`@somebody`!``, the rendered changelog will preserve/render "Fixed a bug,
thanks ``@somebody``!" after the issue link.
* Release roles are of the form ``:release:`number <date>```.
* You may place a comma-separated (whitespace optional) list of issue
numbers after the release role, and this will limit the issues included
in that release to that explicit list.
* Otherwise, releases include all relevant issues as outlined above and
in :doc:`/concepts`.
Then build your docs; in the rendered output, ``changelog.html`` should show
issues grouped by release, as per the above rules. Examples: `Releases' own
rendered changelog
<http://releases.readthedocs.org/en/latest/changelog.html>`_, `Fabric's
rendered changelog <http://docs.fabfile.org/en/latest/changelog.html>`_.
Optional styling additions
==========================
If you have any nontrivial changelog entries (e.g. whose description spans
multiple paragraphs or includes their own bulleted lists, etc) you may run into
`docutils' rather enthusiastic bulleted list massaging
<http://docutils.sourceforge.net/sandbox/html4strict/data/simple-lists.html>`_
which can then make your releases look different from one another.
To help combat this, it may be useful to add the following rule to the Sphinx
theme you're using::
div#changelog > div.section > ul > li > p:only-child {
margin-bottom: 0;
}
.. note::
Some themes, like `Alabaster <http://github.com/bitprophet/alabaster>`_,
may already include this style rule.
Metadata-Version: 1.0
Name: releases
Version: 0.7.0
Summary: A Sphinx extension for changelog manipulation
Home-page: https://github.com/bitprophet/releases
Author: Jeff Forcier
Author-email: jeff@bitprophet.org
License: UNKNOWN
Description: UNKNOWN
Platform: UNKNOWN
Classifier: Intended Audience :: Developers
Classifier: License :: OSI Approved :: BSD License
Classifier: Operating System :: MacOS :: MacOS X
Classifier: Operating System :: Unix
Classifier: Operating System :: POSIX
Classifier: Programming Language :: Python
Classifier: Programming Language :: Python :: 2.6
Classifier: Programming Language :: Python :: 2.7
Classifier: Programming Language :: Python :: 3.2
Classifier: Programming Language :: Python :: 3.3
Classifier: Topic :: Software Development
Classifier: Topic :: Software Development :: Build Tools
Classifier: Topic :: Software Development :: Libraries
Classifier: Topic :: Software Development :: Libraries :: Python Modules
LICENSE
MANIFEST.in
README.rst
dev-requirements.txt
setup.py
tasks.py
docs/changelog.rst
docs/concepts.rst
docs/conf.py
docs/index.rst
docs/todo.rst
docs/usage.rst
releases/__init__.py
releases/_version.py
releases/models.py
releases.egg-info/PKG-INFO
releases.egg-info/SOURCES.txt
releases.egg-info/dependency_links.txt
releases.egg-info/top_level.txt
tests/changelog.py
\ No newline at end of file
This diff is collapsed.
__version_info__ = (0, 7, 0)
__version__ = '.'.join(map(str, __version_info__))
from docutils import nodes
# Issue type list (keys) + color values
ISSUE_TYPES = {
'bug': 'A04040',
'feature': '40A056',
'support': '4070A0',
}
class Issue(nodes.Element):
@property
def type(self):
return self['type_']
@property
def backported(self):
return self.get('backported', False)
@property
def major(self):
return self.get('major', False)
@property
def number(self):
return self.get('number', None)
@property
def line(self):
return self.get('line', None)
def __repr__(self):
flag = ''
if self.backported:
flag = 'backported'
elif self.major:
flag = 'major'
elif self.line:
flag = self.line + '+'
if flag:
flag = ' ({0})'.format(flag)
return '<{issue.type} #{issue.number}{flag}>'.format(issue=self,
flag=flag)
class Release(nodes.Element):
@property
def number(self):
return self['number']
def __repr__(self):
return '<release {0}>'.format(self.number)
[egg_info]
tag_build =
tag_date = 0
tag_svn_revision = 0
#!/usr/bin/env python
from setuptools import setup
# Version info -- read without importing
_locals = {}
with open('releases/_version.py') as fp:
exec(fp.read(), None, _locals)
version = _locals['__version__']
setup(
name='releases',
version=version,
description='A Sphinx extension for changelog manipulation',
author='Jeff Forcier',
author_email='jeff@bitprophet.org',
url='https://github.com/bitprophet/releases',
packages=['releases'],
classifiers=[
'Intended Audience :: Developers',
'License :: OSI Approved :: BSD License',
'Operating System :: MacOS :: MacOS X',
'Operating System :: Unix',
'Operating System :: POSIX',
'Programming Language :: Python',
'Programming Language :: Python :: 2.6',
'Programming Language :: Python :: 2.7',
'Programming Language :: Python :: 3.2',
'Programming Language :: Python :: 3.3',
'Topic :: Software Development',
'Topic :: Software Development :: Build Tools',
'Topic :: Software Development :: Libraries',
'Topic :: Software Development :: Libraries :: Python Modules',
],
)
from invocations import docs
from invocations.testing import test
from invocations.packaging import release
from invoke import Collection
from invoke import run
from invoke import task
@task()
def integration_tests():
"""Runs integration tests."""
run('inv test -o --tests=integration')
ns = Collection(test, integration_tests, release, docs)
This diff is collapsed.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment