On Fri, Oct 04, 2002 at 02:05:32AM +1000, Donovan Baarda wrote: > The reason I said site-packages is the _right_ way, is it makes mailman > modules usable from other applications. However, I agree that we shouldn't > _require_ application specific modules to be in site-packages, particularly > when upstream don't package that way. As you pointed out there are plenty of > good reasons not to put stuff in site-packages.
just as an example, i am working on packaging spyce [1], and it does not put any of its module files in a directory like mailman does. thus all of the scripts using those module file would have to be changed from: import spyceModule to something like: from spyce import spyceModule which is not a fun change to have to make. > Is there any cases you can think of where 'dpkg -L <python-foo> | grep *.py' > will not be sufficient to identify the files to be "registered"? why doesn't python-central handle the (re)compilation of python modules. it can just get the list using "dpkg -L <python-foo> | grep *.py". that way, package postinst scripts dont have to worry about the details and we wont have to run dpkg-reconfigure, which could, for example, ask debconf questions again. [1] http://spyce.sourceforge.net/ -- gram
pgpexbbG3Un9n.pgp
Description: PGP signature
