On Wed, 2003-08-20 at 07:09, Josselin Mouette wrote: > In order to make it up to date, and to match current packaging > practices, I have prepared a draft for a python policy update. > It is available at: http://people.debian.org/~joss/python/ > > It includes clarifications, a new section on bytecompilation, treats the > case of private modules, and appendix B now describes a transition like > the current one (which is likely to happen again in the future). 3.1.1: "A program using /usr/bin/python as interpreter can come up with private python modules. These modules should be installed in /usr/lib/site-python/module, /usr/lib/pythonX.Y/site-packages/module (where pythonX.Y is the current python version) or /usr/lib/package. In the latter case, this directory should be added to sys.path at the program startup. Such a package must depend on "python (>= X.Y), python (<< X.Y+1)"." pydance comes with a number of "modules", which are actually its core source code split into managable files. It installs these to /usr/share/games/pydance, and doesn't byte compile these. Based on my reading of this section, this is now not allowed anymore. However, I don't see a good reason for disallowing this. By not bytecompiling the modules, it means that the package works on any version of Python and Pygame meeting its minimum requirements, which is both 2.2 and 2.3. It is entirely platform-independent data, which means it can go into /usr/share, and be replicated across platforms more easily (although this doesn't matter much in the case of pydance specifically, I can see it mattering for other programs). Is there a reason that programs should bytecompile their modules? The startup time reduction, at least in pydance's case (6800 lines, 27 files) is unmeasurable, it takes up more space, and means backporting the package becomes necessary for testing users. -- Joe Wreschnig <piman@debian.org>
Attachment:
signature.asc
Description: This is a digitally signed message part