Re: The Python Registrar
On Fri, Feb 22, 2002 at 07:03:59PM -0500, Jim Penny wrote: On Sat, Feb 23, 2002 at 10:38:17AM +1100, Donovan Baarda wrote: On Tue, Feb 12, 2002 at 12:05:22AM +0100, Bastian Kleineidam wrote: [...] Did you see my analysis and modified register-python-package script? I posted it under a misleading subject by mistake (responded to another thread that migrated onto it). IMHO python programs are much easier. OK, I will agree with that. The python-central approach attempts to provide a single package that supports multiple versions of python. Education of end-users and even packagers is important. It cannot be overemphasized to all involved that this works only for pure python modules (and maybe pure python programs). It does not, can not, and probably will never work for python C-extension modules. Yeah, but the policy already acknoleges and supports that, and quite well. This does worry me a bit. It requires end-users to know the difference. How do we educate them? End users don't have to know the difference, provided packagers get it right. The dependancies will handle it all for them. Ah, but they do. Some packages install automatically, even in places that they are not necessarily wanted (pure python modules). Some never install automatically, even in places where they are wanted (C-extension modules). [Although C-extension modules should be automatically upgraded when the default python changes.] This is really quite different behavior and requires whoever has root to know and make the distinction. Restated, if you think of these packages only as python modules, it may violate the principle of least surprise that sometimes you install a package and forget about it, and other times you install a package and have to reinstall each time an additional python is introduced to the system you administer. Jim Penny
Re: policy 2.3 para 2
On Sat, Feb 23, 2002 at 10:11:41PM +, Julian Gilbey wrote: On Sat, Feb 23, 2002 at 12:45:07PM +1100, Donovan Baarda wrote: It may be that as python is simpler, we can simply have a script in a python-common package which does something like (pardon me if I get [... sample scripts...] It's funny how minds think alike... did you write these before or after python-central, or did you base them on it. There is a lot in common :-) What's python-central? A suggested way for pure-python modules to support multiple versions of Python, based on the emac'en registry idea. It is implemented as a package called python-central. http://people.debian.org/~calvin/python-central/ (That may answer your question 8-) maybe he grabbed ideas from your post then :-) -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key --
Re: The Python Registrar
On Sat, Feb 23, 2002 at 03:31:26PM -0500, Jim Penny wrote: On Fri, Feb 22, 2002 at 07:03:59PM -0500, Jim Penny wrote: On Sat, Feb 23, 2002 at 10:38:17AM +1100, Donovan Baarda wrote: On Tue, Feb 12, 2002 at 12:05:22AM +0100, Bastian Kleineidam wrote: [...] Did you see my analysis and modified register-python-package script? I posted it under a misleading subject by mistake (responded to another thread that migrated onto it). IMHO python programs are much easier. OK, I will agree with that. The python-central approach attempts to provide a single package that supports multiple versions of python. Education of end-users and even packagers is important. It cannot be overemphasized to all involved that this works only for pure python modules (and maybe pure python programs). It does not, can not, and probably will never work for python C-extension modules. Yeah, but the policy already acknoleges and supports that, and quite well. This does worry me a bit. It requires end-users to know the difference. How do we educate them? End users don't have to know the difference, provided packagers get it right. The dependancies will handle it all for them. Ah, but they do. Some packages install automatically, even in places that they are not necessarily wanted (pure python modules). Some never install automatically, even in places where they are wanted (C-extension modules). [Although C-extension modules should be automatically upgraded when the default python changes.] This is really quite different behavior and requires whoever has root to know and make the distinction. The packages, provided they are built right, will be pretty self explanitory. Installing python-foo will install python-foo for the default python, python2.1-foo will install python-foo for python2.1. You are right that if python-foo happens to be a python-central package, it will also install for any other installed and supported python versions, but I can't see that this is a problem. If it is a python-central package, there will be no corresponding python2.1-foo package. For C module's, admins wanting to add python-foo for version 2.1 will have to explicitly install python2.1-foo. Note that if python2.1 happens to be the default python, python-foo will be an empty package that depends on python2.1-foo. Of course, the current policy does not require that packagers support all versions of python, so there is no garrentees that python2.1-foo will exist, or that a python-central python-foo will support python2.1. A quick glance at the dependancies will tell you what python-foo works for. Restated, if you think of these packages only as python modules, it may violate the principle of least surprise that sometimes you install a package and forget about it, and other times you install a package and have to reinstall each time an additional python is introduced to the system you administer. You don't have to re-install every time an additional python is introduced. If python-central becomes accepted as part of the policy, installing a new python will compile all python-central modules for the new python in the pythonX.Y's postinst. -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key --
Re: The Python Registrar
On Sat, Feb 23, 2002 at 10:38:17AM +1100, Donovan Baarda wrote:
On Tue, Feb 12, 2002 at 12:05:22AM +0100, Bastian Kleineidam wrote:
Hello.
The first version of the python-central package is online at
http://people.debian.org/~calvin/python-central/
It provides support for installing pure Python modules independent
of the Python version (see Python Policy 2.2.3).
[...]
Did you see my analysis and modified register-python-package script? I
posted it under a misleading subject by mistake (responded to another thread
that migrated onto it).
OK, I got creative and figured out a way the python-central could work
without using an emac's style registry, instead just using the existing dpkg
Depends: information.
This new version of register-python-package has shrunk to under 180 lines,
and is much simplified over the original. The usage has been reduced to;
usage: ./register-python-package {configure|remove} package name
It will determine if it is configure/removing a python version or python
module from the package name. Any package that contains *.py files in
/usr/lib/python/site-packages is assumed to be multi-version python module.
The versions of python that a multi-version python module supports is
determined by the pythonX.Y entries in the package's Depends:.
An example for a python-foo module that works for python version 1.5-2.1
would have the following dependancies;
Depends: python1.5 | python1.6 | python2.0 | python2.1, python-central
Any python package with python-central support, including pythonX.Y
packages, would call in it's postinst;
register-python-package configure package-name
and in its prerm would call;
register-python-package remove package-name
For a pythonX.Y package, installing will symlink and compile all modules
with files in /usr/lib/python/site-packages that have compable dependancies.
For a python-foo package, installing will symlink and compile the module for
all installed and compatible python versions. Removing will do the correct
inverse.
Comments welcome. This one is a bit more tested than the last.
--
--
ABO: finger [EMAIL PROTECTED] for more info, including pgp key
--
#!/bin/sh
# the python registrar
# directory with registered packages
CENTRAL=/var/lib/python-central
# python command to byte-compile a file
BYTECOMP=import sys,py_compile;py_compile.compile(sys.argv[1],sys.argv[2])
# directory for installed .py files
IN=/usr/lib/python/site-packages
# get_modules pythonX.Y package
# return installed multi-version python packages that work for the
# specified python package
get_modules() {
PYTHONXY=$1
RET=
for p in `dpkg -S /usr/lib/python/site-packages 2/dev/null | sed
's#,\|:.*$##g'`; do
if dpkg -s $p | egrep ^Depends:.* $PYTHONXY([ ,]|$) /dev/null 21;
then
RET=$RET $p
fi
done
}
# get_versions package name
# return installed versions of python supported by the python package
get_versions () {
DEPENDS=`dpkg -s $1 | grep ^Depends: | cut -d: -f2`
RET=
for PYTHONXY in `ls /usr/bin/python?.? | cut -c 10-`; do
if echo $DEPENDS | egrep $PYTHONXY([ ,]|$) /dev/null 21; then
RET=$RET $PYTHONXY
fi
done
}
# module_compile package name pythonX.Y package
# symlinks and compiles a package for the specified python version
module_compile () {
PACKAGE=$1
PYTHONXY=$2
PYTHON=/usr/bin/$PYTHONXY
OUT=/usr/lib/$PYTHONXY/site-packages
# look for .py files in the package
for i in `dpkg --listfiles $PACKAGE | grep ^$IN/.*\.py$ | sed
s#^$IN/##`; do
# install potentially missing (sub)directories
DIRNAME=`dirname $OUT/$i`
install -d -o root -g root -m 0755 $DIRNAME
# make relative link
REL=../..
while [ $DIRNAME != $OUT ]; do
REL=../$REL
DIRNAME=`dirname $DIRNAME`
# prevent infinite loops
if [ $DIRNAME = / -o $DIRNAME = . ]; then
exit 1
fi
done
# REL points to /usr/lib now
ln -sf $REL/python/site-packages/$i $OUT/$i
# byte-compile package .py files
$PYTHON -O -c $BYTECOMP $OUT/$i $OUT/${i}o
$PYTHON -c $BYTECOMP $OUT/$i $OUT/${i}c
# fix output file mode
chmod 0644 $OUT/${i}[co] || true
done
}
# module_clean package name pythonX.Y package
# removes symlinks and bytecode of a package for the specified python version
module_clean() {
# remove symlink and byte-compiled files
PACKAGE=$1
PYTHONXY=$2
OUT=/usr/lib/$PYTHONXY/site-packages
for i in `dpkg --listfiles $PACKAGE | grep ^$IN/.*\.py$ | sed
s#^$IN/##`; do
rm -f $OUT/$i $OUT/${i}c $OUT/${i}o
done
# remove directories
for i in `dpkg --listfiles $PACKAGE | grep ^$IN/ | sort -r | sed
s#^$IN/##`; do
if [ -d $OUT/$i ]; then
