Re: Opinions on pychecker bug 137320?
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 <abo@minkirri.apana.org.au>
http://minkirri.apana.org.au/~abo/
Reply to: