ralphbean/bugwarrior — pull request #93 by coddingtonbear (2014-03-05 03:43:18+00:00)
Title: Major bugwarrior refactor

Sorry @ralphbean, for this patch bomb -- this may have gotten a bit out of hand, but I do think this will be a bit easier to maintain and add to.

* Separates the concept of `Service` from that of `Issue`.
* `IssueService` subclasses now return generators of issues (rather than lists of dictionaries)
* `Issue` subclasses now encapsulate foreign records directly.
* They still support the normal dictionary operators, though, so the interface has been extended more than changed.
* `Issue` subclasses are required to implement two methods:
* `to_taskwarrior`: Transforms from the foreign record (and any extra information supplied by
the service) into a taskwarrior dictionary.
* `get_default_description`: Returns the description used by earlier versions of BugWarrior.A
* Provides a simple way of defining UDAs that this issue can use (and will be stored in TaskWarrior)
* Defines a 'primary key' -- a tuple of fields (which can be UDAs) which will be used for uniquely
identifying this record. This will be used as the primary way of mapping foreign records to local
records, but by default will fall-back to using description-based matching.
* Standardizes configuration file key names such that they are always prefixed by the service name. (this will
allow people to use `[default]` if they're feeling particularly clever).
* Allows one to customize description generation using a simple Jinja template.
* Adds tests.
* Currently, there are only basic transformation tests that confirm that the Service can be instantiated
and verifies that the issue class will properly transform a given record into the expected format.
* Multiprocessing is always used. Allowing one to select that this use only a single process would have
somewhat complicated things, and I couldn't think of a compelling to provide for both solutions.

**NOTE**: Requires the latest `develop` version of Taskwarrior.

I'd suggest a major version bump for this given that:

* The class hierarchy and API has been changed significantly.
* Many configuration settings have been standardized, and all services now use their service name as a prefix.