Sergio Talens-Oliag wrote:
Hello all,
I was reading the last messages to the list and I've noticed that all python
packages I have are pure python and I that I could install them for all
python versions (at least for python >=2.3), but if I install the code on
/usr/lib/site-python/ the code will only work with the current python
version and the multiple package solution looks an overkill, as some people
said.
This is not entirely correct; they will work for all versions of python,
but will have a few minor uglynesses;
1) any time something in /usr/lib/site-python is imported by a version
of python different to the version used to compile the *.pyc's
(typically the default version of python), the *.pyc file will be
re-compiled. Provided the user it is running as does not have write
access to /usr/lib/site-python, the old *.pyc's, will not be
over-written. This introduces a mild overhead every time.
2) any time something in /usr/lib/site-python is imported by a
non-default version of python running as root, it's *.pyc will be
re-compiled using that version of python and over-written.
Provided only the default version of python is used, or that only
non-root users run other versions of python this is not a problem. Even
if the *.pyc's do get over-written, it is not a serious problem, and
most people would never notice.
My proposal for those cases is simple: why don't we remove
/usr/lib/site-python/ from the python path and link the contents of that
directory on /usr/lib/pythonX.Y/site-python/ on the postinstall of pure
python packages that install their code on /usr/lib/site-python/?
With this system, when a new pythonX.Y package enters the archive it can
build his own linked version of /usr/lib/site-python/, leaving the compiled
files on /usr/lib/pythonX.Y/site-python/. The main advantage is that the
package is available to all installed python versions and supports zero work
transitions.
[...]
Of course all that should be elaborated and formalized a little bit to enter
into the Policy document, but I would like to know what do others thing
about it and know what other solutions or changes have been proposed for the
next version of the policy, if any.
This is exactly like the proposal already described but not yet
supported in the current Python Policy. The only difference is it
suggests using /usr/lib/python/site-packages instead of
/usr/lib/site-python.
The only reason this is not yet supported is no-one has yet made it
work. The closest thing is the work done on python-central...
--
Donovan Baarda
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
