Re: python-central comments
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 abo@minkirri.apana.org.au for more info, including pgp key
----------------------------------------------------------------------
Reply to: