Re: python packaging infrastructure
Joe Wreschnig writes:
> On Thu, 2006-01-12 at 14:44 +0100, Matthias Klose wrote:
> > - 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.
People will find their modules in the standard place after
installation, handle by a script in the postinst. The only place
where you do see the difference will be the output from some tools
like `dpkg -L' and `dlocate'.
An alternative would be to modify the python implementation to
byte-compile into another directory and import from that directory,
there exist a patch for an earlier version, but it's not integrated
upstream. There is a reason nobody does want to touch the import
code.
> > - 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.
yes, the current version supports that notation.
> > 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.
Private modules should be kept as they are. The existance of a
Python-Version attribute lets the central/support package know, that a
byte compilation with the new version is needed.
> > - 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.
Turning it off by default sounds ok.
> > - 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.
dpkg does have support for the installed size, you could do that;
unless it's not done by some helper script nobody will use it anyway ;)
> > 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.
well, current practice is to use dh_python to add the required
dependencies and support scripts, not to move files to some location.
> > 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.
that's understood. it's unfortunate that the package wasn't uploaded
to experimental first to sort out things. otoh, the change to
dh_python could be reverted in debhelper without doing any harm.
> > 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.
Joss didn't yet comment. I really do not want to have a packager/user to
understand two different things for extensions and modules, and
probably a third one for private modules.
> > 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.
I do not care how the tool/package is called as long it does have
support for all kind of python packages and we can use the package
management tools to query about these packages. The "already in the
archive" argument doesn't really count. Should I just upload
python-central without discussion as well?
Matthias
Reply to: