On Thu, 2003-09-11 at 05:06, Kenneth Pronovici wrote: > Hi, > > I've taken over the pychecker package from Arto Jantunen, and I'm > looking over the remaining bugs. One of the three is #137320: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=137320 > > It requests that the Pychecker modules be installed in the Python search > path, so they can be imported, rather than in /usr/share/pychecker. > (The modules are intended to be used this way; it's one of the > documented usage scenarios described on the upstream website.)
> I think that this bug is important enough to be dealt with, and I'm > looking for opinions on the best way to do it. I keep thinking I should put some effort into fixing up the current python policy and support to clean this up... time... where is some :-( > Right now, what I am thinking of doing is creating a set of > pythonX.Y-pychecker packages. The pychecker package would depend on > python2.3-pychecker and would suggest the rest. The /usr/bin/pychecker > wrapper would be changed to use /usr/bin/python2.3 by default. If the > user used $PYTHONVER to specify an alternate version other than 2.3, the > wrapper would look for the Python modules in the appropriate > /usr/lib/pythonX.Y/site-packages directory and call /usr/bin/pythonX.Y. > If the site-packages directory was not found, the wrapper would return > an error something like "Pychecker modules not available for python > version X.Y; install the pythonX.Y-pychecker package first." I assume > that I would provide packages and support for all "standard" Debian > Python versions (right now 1.5, 2.1, 2.2, 2.3); requesting an > unsupported version with $PYTHONVER would result in an error. 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. > The main thing I think this loses over the existing solution is that the > wrapper script would no longer directly support using the pychecker > modules with a version of Python that is in the user's $PATH but is not > managed by dpkg. I see this to be of little consequence, but I don't > know how others feel about it. the philosophy behind the python policy is python debs only need to support python debs... people using other stuff are on their own. In any case, they could still do this by running pychecker explicitly with their own python; $ /usr/local/bin/python /usr/bin/pychecker It would be up to them to ensure the correct modules etc are on the pythonpath. > Anyone have an opinion about this plan? Is there a downside or some big > hole I'm missing here? Or is there some reason why I would want to > leave the modules in /usr/share/pychecker rather than in the various > site-packages directories? There are two downsides; you introduce a bunch of new packages, and you replicate the same files in each package. There are two better options IMHO; 1) make your own postinst/prerm scripts that handle the complicated symlinking described in the Policy and tagged "unsupported". Have a look at python-central for example scripts for doing this. This is the "best" technical solution, but has the following two problems; it's hard to implement, and the python[X.Y] packages don't yet support "notifying" packages when they are installed/removed. The latter problem means end users will need to manually "dpkg-reconfigure" the pychecker package after installing/removing python[X.Y] packages to ensure pychecker is properly configured for all the installed versions of python. 2) put the modules in /usr/local/lib/site-python, and compile them with /usr/bin/python in your postinst. This is on the pythonpath for all versions of pythonX.Y, so pychecker will be available for any version of python. This has the following three problems; non-default versions of python will have to recompile these modules every time they are imported, if they are imported by 'root' the pyc's will be replaced by the recompiled versions, and the current "python" package will not recompile the pyc's when it changes version. The first problem is not too bad, but introduces a slight overhead when using pychecker with a non-default python. The second problem is more annoying, as it means all subsequent imports of pychecker incur the overhead for the default version of python. The third problem means users will need to manually "dpkg-reconfigure" after upgrading "python" to ensure the pyc's are correctly compiled for the new default version of python. 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. -- Donovan Baarda <[EMAIL PROTECTED]> http://minkirri.apana.org.au/~abo/
