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