[Reportbug-maint] Modularization work in progress
ben+debian at benfinney.id.au
Sat Jun 28 06:10:29 UTC 2008
"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
- 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
\ "The most merciful thing in the world... is the inability of |
`\ the human mind to correlate all its contents." -- Howard |
_o__) Philips Lovecraft |
More information about the Reportbug-maint