[Reportbug-maint] merging common stuff in python-debianbts?

Chris Lawrence lawrencc at debian.org
Wed Jun 4 21:04:53 UTC 2008


On Wed, Jun 4, 2008 at 3:04 PM, Bastian Venthur <venthur at debian.org> wrote:
> im Bastian Venthur, developer of reportbug-ng. I wonder why I haven't
> thought of this before, but since both, reportbug and reportbug-ng are
> written in python and therefore share a lot of functionality, wouldn't
> it be nice to merge some common stuff in a separate library both
> programs could depend on? I'm particularly thinking of the way both
> programs fetch the bugreports. If I remember correctly, reportbug gets
> the information from bugs.d.o's webinterface by parsing the html answer
> of a specific request. reportbug-ng did that too in the beginning but
> dropped it in favor of bugs.d.o's SOAP interface.
>
> What I'd like to have is a generic python lib like "python-debianbts"
> which provides an interface for querying the debian BTS. It could have
> implemented both ways: via html parsing and SOAP which could be
> configurable via some kind of option. The important idea is to have a
> single interface (from python's POV) to get the information, but of
> course more than one way under the hood how it gets the information.
>
> If something changes in debians BTS we don't have to change both
> reportbug and reportbug-ng but just the python-debianbts lib.
>
> What do you think? We could develop and maintain the lib together. If
> you're interested, I propose to define the API of the lib (which methods
> retun which datatypes and so on) and then could take reportbug's HTML
> parsing as one implementation of the interface and reportbug-ng's SOAP
> stuff as a second one.
>
> I'd be happy to hear your ideas!

My working plan at the moment is to move most of the reusable code in
reportbug into a separate package, tentatively named 'dreportbug'
(that's the name I've chosen in my git-svn tree, to avoid a name
conflict between 'reportbug' the script and reportbug the Python
package).  So debianbts.py would become dreportbug.debianbts.

So far most of the reportbug modules have moved in under the same
names (reportbug_* is now dreportbug.*, reportbug.py ->
dreportbug.utils, the rest are now * -> dreportbug.*) and I've put
together a skeleton dreportbug.bugreport that will eventually
encapsulate much of the functionality in utils in a "bugreport"
object, presumably something that would also be reusable by
reportbug-ng.  (So far it's mostly a constructor and a __unicode__
function that replaces reportbug.generate_blank_report, but the idea
is to create the object earlier and stuff stuff into it rather than
waiting until the end, and move some of the logic in there too.)  I've
also gone through and killed some legacy cruft for other BTSes (some
of which got culled independently in the 3.41 release).

The git tree is about 90% there; I still need to convert over
querybts, all the tests that were added to the source tree in 3.40,
and rebase on the 3.41 changes, but I'm hoping to be able to push it
back into svn when I get back on the real Internet and have some time
to deal with the fallout.


Chris



More information about the Reportbug-maint mailing list