Re: python-central comments
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? ;-)
> > - A separate command to install a python version would be useful.
> > Assume I rename the packages again, or you want it to use for
> > jython as well.
>
> As the person who originally "simplified out" the seperate command for
> installing python versions, I can see your point.
>
> Currently the register-python-package does have seperate code for installing
> python and modules internally. I originaly thought that the extra flexibility
> the seperate commands gave was unnecisary.
>
> 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)?
> > - 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
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.
> > - 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.
> > - 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/<package> \
> --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 problem is that python-central requires *.py dirs to be symlinked from a
> different directory for each python version installed. For this to work,
> Mailman would need to install it's *.py files into a directory not on any
> python-path, and python-central would need to create symlinks to them for
> each supported python version in a different directory, where that directory
> _is_ on the python-path for the appropriate python version.
>
> 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 ;-)
There are cases, where a module of an application could be reused and
be put into /usr/lib/python.
> > Hope you can implement this missing bits for 0.x ;-)
>
> have you been looking at 0.3?
yes, I commented on 0.3. looking for 0.4 ...
Thanks, Matthias
Reply to: