[Reportbug-maint] Modularization work in progress

[Ben Finney]

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

> mh, I just gave a look to Ben's "branch": do we really need an
> additional level (reportbuglib) into /usr/share/reportbug/ ?

Not in the long term. That's only temporary as a way of minimising the
impact on the existing code.

> I don't know how Chris' tree looks like, but having (-> means
> installed into)
> 
> <svn trunk>/bin/reportbug -> /usr/bin/reportbug
> <svn trunk>/reportbug/<files>.py -> /usr/share/reportbug/
> 
> so that we can import reportbug (the trick can be adding /usr/share
> to sys.path and leaving reportbug/ in it, as of now, I think) it
> seems to me a "cleaner" solution.

Part of the goal here as I understand it is to facilitate future
migration to using existing standards for Python. That includes things
like:

- writing a 'setup.py' to take advantage of Python's 'distutils'
  functionality to manage the software installation

- using Debian's 'python-support' or 'python-central' to manage the
  moving of files and the paths (i.e. no modules under
  '/usr/share/reportbug/' at all)

- installing the library code so that the 'reportbuglib' Python
  package namespace (or 'reportbug' as it will eventually be) is
  already in the path ready to import

- removing the hack of 'sys.path' that is currently done by the
  'reportbug' and 'querybts' programs

That, to me, is the clean solution we're aiming for: making the code
in our project conform much closer to conventions for other Python
packages.

-- 
 \        "The most merciful thing in the world... is the inability of |
  `\         the human mind to correlate all its contents."  -- Howard |
_o__)                                                Philips Lovecraft |
Ben Finney