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

[Ben Finney]

"Sandro Tosi" <matrixhasu at gmail.com> writes:

> I'm replying to the original email, since I'm explaining my thoughts
> about that:

Does the original message's author subscribe to 'reportbug-maint'? I
don't see any other recipients. Should they be included in the
discussion?

> > 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

This leads to a separate question of why the 'reportbug-ng' project
exists, and whether the separation should continue, instead of
concentrating our work on the existing 'reportbug' project. That may
be more appropriate for a separate thread though.

> > What I'd like to have is a generic python lib like
> > "python-debianbts" which provides an interface for querying the
> > debian BTS.

This is an excellent idea.

> > 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.

Sure, I'd like to see this become reality.

Should we even bother to specify the HTML webscraping, though?
Shouldn't we use the more structured and direct SOAP interface
primarily, instead of codifying web-scraping as a common supported
interface?

I would prefer to treat reportbug's HTML scraping as legacy
functionality, to be migrated away from when it becomes feasible to do
so, not continue to support it in a common library.

> Since due to my professional work, I prefer a lot of simple "tools"
> to do the job (a-la-unix) to join together to fulfill the higher
> requests. So, personally, I'd like to "externalize" all common
> activities (Bastian pointed out one, BTS interrogation) in a
> completely separated package, but letting it be reusable.

Yes, I agree.

Since this interface would be closer tied to the Debian BTS than to
any particular tool, would it make sense to define it as part of the
'debbugs' project? Perhaps not, since debbugs is not written in
Python; but perhaps this Python library interface could be maintained
as part of that project to help it remain in sync with the interface.

Are we talking about an interface to the Debian BTS only, or to any
'debbugs' instance? If the latter, it would make more sense for the
package to be named so it's associated with 'debbugs'; e.g.
'python-debbugs'.

> I know, it would be a lot of work, but this way we can leverage
> existing (i.e. tested) code while contributing with other to be used
> in other programs.

I'm interested to see this happen. It is timely too, since we already
have interest within the 'reportbug' project of making the code more
modular; the interaction with the BTS seems a prime candidate to focus
on.

-- 
 \      "I stayed up all night playing poker with tarot cards. I got a |
  `\               full house and four people died."  -- Steven Wright |
_o__)                                                                  |
Ben Finney