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.