> for this scheme, you don't need to make /usr/bin/pychecker handle
> alternate python versions explicitly. Just put '#!/usr/bin/python' at
> the front, and the correct /usr/lib/pythonX.Y will be on the pythonpath.
> If they explicitly use a different python version by running;
>
> $ python2.1 /usr/bin/pychecker
>
> then /usr/lib/python2.1/ will be on the pythonpath instead. In the case
> of trying to use pychecker with python2.1 without python2.1-pychecker
> installed, they will get an import exception. You could catch this
> exception and give a more meaningful error message, but I suspect anyone
> running pychecker would be clueful enough to figure out the problem
> themselves from the exception.
Actually, the kicker is, pychecker isn't a Python script - it's a shell
script (condensed below):
#!/bin/sh
if [ ! $PYTHONVER ]; then
for i in /usr/bin/python \
/usr/bin/python2.2 \
/usr/bin/python2.1 \
`which python`
do
if [ -x $i ]
then
$i /usr/share/pychecker/checker.py $@
break
fi
done
else
python$PYTHONVER /usr/share/pychecker/checker.py $@
fi
I was trying to come up with a good way to maintain this flexibility
(which users might depend on?) while still allowing for the packages to
be imported.
Maybe that's not worth it?
> the philosophy behind the python policy is python debs only need to
> support python debs... people using other stuff are on their own.
Ok - that is what I had thought.
> In any case, they could still do this by running pychecker explicitly
> with their own python;
>
> $ /usr/local/bin/python /usr/bin/pychecker
True. Well, it's more like:
/usr/local/bin/python /usr/lib/pythonX.Y/site-packages/pychecker/checker.py
But it is possible.
> There are two downsides; you introduce a bunch of new packages, and you
> replicate the same files in each package.
'Course, that's the same problem that every other Python package has,
right?
> There are two better options IMHO;
> (snip)
> .
> .
> .
> Of the two, probably the second is currently your best option as it will
> always work, even if sub-optimally, with minimum effort. The first is
> technically superior, but the lack of support means end users will need
> to manually ensure it is configured correctly otherwise it will not
> work.
Ok, I see what you're saying. I agree, the second option is probably
the best at this time. If my postinst builds the .pyc files with the
default python, and assuming no one runs pychecker as root with a python
version other than the default, this is as close to an optimal best-case
as I'm going to get. At least until the transition from 2.3 to 2.4,
when all of the .pyc files will become invalid again. <sigh>
Thanks,
KEN
--
Kenneth J. Pronovici <pronovic@debian.org>
Attachment:
pgpeVuOYE9RA7.pgp
Description: PGP signature