"Sandro Tosi" <[EMAIL PROTECTED]> 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 _______________________________________________ Reportbug-maint mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/reportbug-maint
