Re: version independent pythin packages: ?
On Thu, Aug 07, 2003 at 12:58:25PM +1000, Donovan Baarda wrote:
> The only problem is when someone with write access to
> /usr/lib/site-python uses a non-default python... the pyc's will be
> "updated" for the non-default python.
>
> After testing, it seems that there is no way to prevent root from
> updating the pyc's when using a non-default python. However, even if
Yes, even chmoding the .pyc file won't work.
> this does occur, everything will still work, it will just be slightly
> less optimal when using the default python. The only solution is "root
> should never use the non-default python when importing modules from
> /usr/lib/site-python"... which may or may not be OK.
For most programs this should not really be a big issue. Most of the
time, people tend to use mostly one python version on production
machines. The worst case I've seen with missing/inapropriate .pyc files
was on a cgi based web application, where the performance increase we got
when fixing the problem was noticeable by end users. For long running
processes, the import is done only once, so the loss of time is evened
out in the long run.
> Given the complexity of the alternatives, this is a simple solution that
> fixes the problem with only minor issues. I'd be tempted to make this
> the solution and put it into the Python policy.
+1
> Anyone else agree?
>
> Other things to think about;
>
> Python applications using the default Python with their own modules not
> in /usr/lib/site-python... not an issue?
They are expected to configure their own PYTHONPATH, are they not?
> Making sure all the pyc's are re-compiled when the default python is
> updated.
Yes. Should not be too difficult.
> A brute force approach is to have the python packages post-inst run
> "dpkg-reconfigure" over every package that depends on "python", and
> require that packages recompile their pyc files on a "dpkg-reconfigure".
> This has the advantage of "notifying" all these packages when the
> default python has changed so they can do other stuff if they need to.
This would be nice, but packages will take some time to catch up.
Another thing we should take care of is packages which used to be pure
python in version N, and include C extensions in version N+1. The
packages for N+1 should be versioned, but how can we provide a nice
upgrade path? In order to be sure not to break anything, we would have
to make the new python-foobar package depend on python2.X-foobar for X
in (1,2,3).
The last point is how to write dependencies on packages which are ot
available on all python versions. For instance python-docutils needs
python-xmlbase and python-difflib. python-xmlbase exists for python2.1
and 2.2 but not 2.3, and difflib exists for 2.1, but not 2.2 or 2.3. How
should the dependencies be written ?
--
Alexandre Fayolle
LOGILAB, Paris (France).
http://www.logilab.com http://www.logilab.fr http://www.logilab.org
Développement logiciel avancé - Intelligence Artificielle - Formations
Reply to: