Re: python-central 0.4

[Matthias Klose <doko@cs.tu-berlin.de>]

Donovan Baarda writes:
> > I wouldn't call moving some files the packaging hell, and I have yet to
> > understand why /usr/lib/mailman is so much saner or better than
> > /usr/lib/python/site-packages/mailman.
> > I looked into the mailman package. It should not be that much work to
> > adapt it to the python-central framework (moving the Mailman module
> > into .../site-packages/, removing the paths.py hack).
> > And when the mailman Bug#162761 is fixed, I could even provide a patch ;)
> 
> I guess this is an issue of "upstream compatiblity". Sure, packages could be
> restructured to fit the scheme, but the other alternative is to masssage the
> scheme to fit the upstream packages...
> 
> I think that using /usr/lib/python/site-packages/mailman properly is the
> _right_ way to do it, but I can see the argument for /usr/lib/mailman,
> particularly when upstream does it that way.

IMO this is absolutely wrong.

Bastian Kleineidam writes:
> Hi,
> 
> to put the code where my mouth was I tried to make a patch for mailman
> using the python-register utility.
> It was just moving files around - so I could fire up python and
> do an 'import Mailman'.

I originally mentioned mailman as an example for an application. Sure
mailman does consist of a library, which may be worth using in
ordinary python programs. However there _are_ applications with
modules not belonging in the /usr/lib/python tree: Assume a program
foo importing baz.py and bar.py. You cannot simply put these files in
/usr/lib/python:

  - these may not be library modules.

  - they pollute the namespace (assuming you have just another
    application foo2, having its own bar module.
    Even putting them in a separate directory does not help, because
    these directories are all added to sys.path.

So python-central _has_ to handle the case of python files laying
around somewhere (i.e. /usr/lib/foo/{bar,baz}.py), recompiling these
files on python upgrades.

Please design python-central for all kind of packages, do not require
the packages to be adapted to python-central.

> > Conclusion: the python-central framework as it is now offers enough for
> > everyone. If people don't want to use it, they are on their own.
> 
> I think we could add support for the mailman case with minimal hassles...
> 
> The biggest problem I can forsee is this introduces another option that will
> confuse developers... But this can be rectified with "strongly suggests" in
> the python policy.

There should be no confusion telling python-central the locations of
files to be registered.

> > Hmm, reading the Debian policy, the only difference is that Depends only
> > are considered on configuring a package, Conflicts are considered on
> > installing. I dont know whats better, I think either will do.
> > I will adapt the man pages to the Python Policy.
> 
> Give this, I would prefer the "Depends" rather than "Conflicts", as it more
> closely matches what a python version incompatability means... you can
> install the files, but you can't configure them to work.

please send a patch for the policy.

Bastian Kleineidam writes:
> python-central (0.4) unstable; urgency=low
> 
>   * renamed register-python-package to python-register, this way
>     its prefixed with "python" (and its shorter ;)

as long as python-central handles libraries/modules only, it should be
called register-python-library. Don't confuse the packager ;-)


Matthias, away 'til Sunday.