On Mon, Aug 26, 2002 at 07:55:45AM +0200, Matthias Klose wrote: > Donovan Baarda writes: > > On Sat, Aug 24, 2002 at 07:48:31PM +0200, Matthias Klose wrote: > > > Some comments: > > > > > > - python-central should have a configuration option, how files are > > > compiled. Most users don't need compilation with -O. Maybe > > > a debconf option? > > > > Hmm, could be done I guess, but this is already more than the current > > standard offers... can't we add this in _after_ python-central becomes a > > standard? > > or do it right the first time? ;-)
My point was that this is something that can easily be added at a later date, and if we adopt python-central now, then we don't loose anything. > > Now I'm not sure, but I'm also not sure that it is simple to have something > > generic enough to support jython etc. I have a feeling any sort of attempt > > at a generic solution will need to be "fixed beyond compatability" when it > > gets tested in the wild anyway. > > > > Unless someone can come up with some hard examples and possible solutions > > I'd be wary of trying to see the future in this case. > > if python-central should become a standard method, then this should be > decided now. I would favour a more explicit register-python-version(1). > jython doesn't need to be supported, because it uses the python2.1 > library (CC'ed the maintainer)? I guess what I'm getting at is that currently the "detection" of when you are installing a version of python instead of a python module is done by looking at the package name. If there are oddball python packages, this "detection" can easily be made more elaborate. Any explicit 'register-python-version' command is going to need special tweaking for oddball python packages anyway, so this doesn't buy you anything except a more complicated interface. > > > - A package should have the possibility that it's incompatibe with > > > a specific python version or that it only works with specific > > > versions. > > > > This is already supported. Packages that support more than one version of > > python specify it in their dependancies; > > > > Depends: python1.5 | python1.6 | python2.1, python-central > > hmm, so you have to recompile this, when a new python version appears? > Why not register the module with whenever a new pythonX.Y is installed, all the (compatible) modules have to be compiled for it. There is no way around this, unless the package includes pre-compiled *.pyc files, which is a bad idea for other reasons. If you were meant "the package needs to be fixed and re-released when python2.2 becomes the standard", then yes. A module that is incompatible with python2.2 will need to be fixed and re-released to support the default version of python when it becomes python (2.2). Note, however, that the above package will still happily support python1.5 -> python2.1 without any fixes required, even though it doesn't support python (2.2). > register-python-module --incompatible-with=2.0,1.6 > > Then no new upload is needed for a new python version. I think this > was one of the benefits of python-central. You need to have guido's time machine to know if your code is compatible with python 3.1. Instead of specifying what your code is _incompatible_ with, you specify what your code is _compatible_ with, as this is safer. > > > - A command is missing to recompile all registered packages when > > > the default python version changes. > > > > This is not needed. The default python just installs a pythonX.Y package. > > Provided the default pythonX.Y is already installed, then the registered > > packages are already "registered" for it. If then new default pythonX.Y is > > not already installed, then all the packages will be "registered" for it > > when it gets installed as a dependancy of the new "python" package. > > > > Note that I use "registered" in quotes. python-central no longer really > > registers packages, instead it uses the dpkg dependancies to identify what > > packages depend/support on what versions of python. > > yes, I consider this as not optimal. It's needed for the "mailman" case. It's all a case of objectives and requirements. Python-central was build to allow a pure python package to support multiple versions of pythonX.Y. This it does, with the limitation that the modules must be installed in /usr/lib/python/site-packages. Note that this is a more demanding requirement than just "support multiple versions of the default python", which is what I think you are hinting at. Supporting multiple versions of pythonX.Y means being able to install python (2.1), python1.5, python1.6, python2.1, and python-foo where python foo has; Depends: python1.5 | python1.6 | python2.1 | python2.2, python-central and have all of the following commands work; python -c "import foo" python1.5 -c "import foo" python1.6 -c "import foo" python2.1 -c "import foo" Note that 'python2.2 -c "import foo"' would fail because python2.2 is not installed, but would suceed after it is installed. > > > - How do packages like mailman make profit from python-central? > > > They don't install into /usr/lib/python/site-packages, but > > > their python files need to be recompiled on a python version > > > change. > > > > This is tricky. The current register-python-package says this; > > > > will do the correct inverse. Note that if your package > > does not install its .py modules into > > /usr/lib/python/site-packages, the modules wont be regis? > > tered! See the notes on how to do this. > > : > > : > > NOTES > > Python modules should be distributed with the Python Dis? > > tutils. Debian scripts can call this line to install .py > > files into the build-tree: > > python setup.py install --root=$(CURDIR)/debian/<pack?age> \ > > --install-purelib=/usr/lib/python/site-packages --no-compile > > [offtopic: --no-compile saves time, but you don't check that your > files are correct] The --no-compile option is there because we don't want compiled *.pyc files installed in that directory. The compiled *.pyc files are python version dependant, and hence belong in /usr/lib/pythonX.Y/site-packages for each compatible pythonX.Y that is installed. This is what python-central does for you. > > I'm not sure of the upstream Mailman structure, but I suspect this would > > require major work on the part of the packager to re-structure it to support > > this, even if python-central did have some sort of capability for supporting > > modules outside /usr/lib/python/site-packages. In the end, I suspect it > > would be just as easy or easier to re-structure mailman to put it's modules > > in /usr/lib/python/site-packages. I suspect the above NOTE provides a hint > > to make this easier. > > IMO packages should not work around python-central. Consider an > application consisting of /usr/bin/foo and /usr/share/foo/{foo,bar}.py. > This will never be installed into /usr/lib/python. Such a package > should be able to register with python-central, which recompiles the > package when the python version changes. Or else call the package > python-library-central ;-) This is a different (and simpler) requirement than what python-central addresses, and something that could be added to the default python package without python-central, and without requiring any sort of registry. All that would need to be done is have the default python package find and re-compile any packages that have *.py files and depend on "python" in it's postinst. Note that this would not clash with the current python-central implementation as packages that use it would not depend on "python". -- ---------------------------------------------------------------------- ABO: finger [EMAIL PROTECTED] for more info, including pgp key ----------------------------------------------------------------------