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 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? (That may answer your question 8-) Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Debian GNU/Linux Developer Queen Mary, Univ. of London see http://people.debian.org/~jdg/ http://www.maths.qmul.ac.uk/~jdg/ or http://www.debian.org/ Visit http://www.thehungersite.com/ to help feed the hungry
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}
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
and in its prerm would call;
register-python-package remove
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
# 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 2>&1;
then
RET="$RET $p"
fi
done
}
# get_versions
# 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 2>&1; then
RET="$RET $PYTHONXY"
fi
done
}
# module_compile
# 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
# 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
rmdir $OUT/$i || true
fi
