> 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 <[EMAIL PROTECTED]>
pgp3wpNySoUXm.pgp
Description: PGP signature