On Thu, 2006-01-12 at 14:44 +0100, Matthias Klose wrote: > After a long silence (and some work on "unrelated" C++ transitions ;), > an update to the python packaging infrastructure.
Thank you. I've snipped stuff I agree with, or don't have an opinion on yet. > - modules are installed into a directory not directly in sys.path. While I understand the rationale here, this could be *very* confusing for people coming to Debian from other operating systems. > - Add a new field to the control file for binary packages, > XB-Python-Version. The field should list all python versions which > the module/extension is supposed to install to. It should be possible to specify "greater than X.Y" or otherwise we have the same problem (just in a single control field instead across 3 packages). XB-Python-Version: >= 2.2, for example. > The installation and removal of packages is supported by some support > scripts / registry script / name-it-whatever-scripts: > > - Python modules are installed in a directory tree which is managed > by the registry. > > - No directory of the registry is part of sys.path in any python > implementation. How does this affect private modules (/usr/lib/packagename or /usr/share/packagename)? It seems like it would be easier to store them where they belong, and then upgrade them on Python upgrade, rather than managing them in module registery as well. > - Wether to provide "optimized" byte-compiled files. Drop it / keep > it, make it a configuration option. If everything is being compiled by some central program, a configuration option with a default of off seems best to me. But my bias against pyo files is well known. > - Adjust the installed size field. Currently the size of > byte-compiled files is not mentioned in the Installed-Size field. > Get the value at build time, either by a test compilation or an > estimation (double the size of the .py files). Is this really feasible? The installed size will be, rough, source size * (the number of Python versions you have installed + 1), then * 2 if you have pyo files as well, since we're compiling for multiple versions. Since the installed size would vary based on the number of Python versions you have installed, an accurate report via APT would be impossible. > Implementation: There currently exists more than one implementation, > the goal definitely is to have only implementation handling all the > packaging issues mentioned above. > > - python-central (0.1-0.3), done by Bastian Kleinadam some years ago, > only handles binary-all modules. > > - python-support, done by Josselin Mouette, available in the archives, > only handling binary-all modules, supported by an updated dh_python. > > - python-central (0.4), a reimplementation of Bastian Kleinadam's > work, handling python extensions and applications/modules outside > the default sys.path. To not interfer with python-support's > changed dh_python, this has a renamed dh_pycentral. Can be found at > deb http://people.debian.org/~doko/python ./ > The package changing the default python version is at > deb http://people.debian.org/~doko/python-default ./ > > > I'm currently unhappy that the new dh_python breaks current packaging > practice, please let us come to a common approach how to handle the > packaging infrastructure. When writing my initial email, and discussing with Steve, I looked through a lot of packaged modules and programs. At the moment, there's very little common practice between Python-using packages (compare uligo vs. pychecker vs. linda). So I'm not sure it's fair to say anything is breaking current practice, because there really isn't one. > As dh_python currently violates the python > policy, I filed a RC report to debhelper and python-support to prevent > them entering the testing distribution. This also blocks any Python program using dh_python from reaching testing until the issue is resolved, so it behooves us to do this quickly. > Some things about python-support, others may comment about python-central: > > - Some concerns were raised by the release team, that python-support > tracks it's own state instead of using the dpkg database. To keep > track of usable python versions, python-central uses a field > Python-Version in the control file (having values like "2.3, 2.4", > "all", ">= 2.3") Is there some reason python-support couldn't be extended to also do this? I agree it is a better solution than a separate database. > - It doesn't have yet support for extensions and modules outside the > default sys.path. although it should be easy to add these. Unless I misunderstand (either or or python-support) it does, in /var/lib/python-support/bytecompiled. I've built several packages with private Python libraries to test it, and it keeps a list of those directories and rebuilds them. I didn't even have to specify them manually. update-python-modules -b -a is recompiling them. > - python-support's dh_python currently does more on it's own than > dh_pycentral does. > I'm in favour of supporting an infrastructure handling extensions and > modules outside the default sys.path well, which ever this > implementation will look like. It seems to me that it would be easier to extend python-support, which is already in the archive (and as far as I can tell, working basically as intended) to use the proposed control field. -- Joe Wreschnig <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
