Proposal: Reorganizing Python for Python2 (and fixes for the previous proposal)

[jerome.marant@free.fr (Jérôme Marant)]

Hi all,

  I'm reposting this mail on -devel as not all python modules maintainers
  are -python subscribers. Discussions will continue on -python.
  This version contains small modifications from the one firstly posted
  on -python.

Proposal: Reorganizing Python for Python 2.
-------------------------------------------

  The purpose of the proposal is to regorganise python in order to make
  multiple versions and modules installed at the same time.
      
  1) Problem:
    - we want python 2 to enter debian ASAP
    - we do not want to duplicate packages for python 2
    - the python version number is hard coded in the path to
      python modules.
    [FIX:
    - some packages are GPLed and can not (yet) be run with python2.
    ]

  2) Proposal:  
    I'm proposing to reorganise the python tree as follows (I'm considering
  only site packages in this case, are this is what is problematic) :
  
  /usr/lib/python/1.5/site-packages
    This directory contains python 1.5.2 modules that are not compatible
    with greater version of python (i.e. 2.0)

  /usr/lib/python/2.0/site-packages
    This directory contains python 2.0-specific modules. These are not compatible
    with earlier versions of python (i.e. 1.5).

  /usr/lib/python/site-packages
    This directory contains python packages that are runnable "with
    all pythons".

  3) Sceneries:
    . Python 1.5 was installed and we decide to install 2.0
      python 1.5 specific packages are installed in ...python/1.5/site-packages
      other packages are installed in ...python/site-packages

      * we make /usr/bin/python point to python 2 thanks to alternatives
      * we run a compileall.py in python/site-packages in order to
        get them byte-recompiled for 2.0

    . 1.5 and 2.0 are both present on the system
      and we uninstall 1.5

      * nothing to do

    . 1.5 and 2.0 are both present on the system
      and we want to uninstall 2.0

      * we remove the alternative so that /usr/bin/python points to 1.5
      * we run compileall.py in python/site-packages in order to get them
        byte-recompiled for the earlier version (i.e. 1.5)

    . 2.0 in the only one installed

      * nothing to do

  4) Modifiying the interpreters:
    .The interpreters have to dynamically look for the following path, in
    the following order:
    - /usr/lib/python/<their version>/site-packages
    - /usr/lib/python/site-packages

    . postint
      Add compileall for /usr/lib/python/site-packages

    . postrm
      Add compileall for /usr/lib/python/site-packages if another
      interpreter is present on the system.

    . control    
      Add a versioned provides, Provides: python (= 2.0)
      [FIX: I'm not sure this versioned provides would work if
       we want both 1.5 and 2.0 to be installed at a time]


  5) Modifying site packages:
    People will have to check the compatibility of they modules with
    1.5 and 2.0 and install them in the new tree as explained in the
    proposal.

    So, 3 kinds of dependencies :
      Depends: python (>= 2.0)  for /usr/lib/python/2.0
      [FIX: Depends: python2]

      Depends: python (>= 1.5), python (<= 1.5.2) for /usr/lib/python/1.5
      [FIX: Depends: python (>= 1.5)]

      Depends: python (>= 1.5) for /usr/lib/python/site-packages
      [FIX: Depends: python (>= 1.5) | python2]


  Did I miss something ?

  6) If this can be implemented, we'll have to:

  - make new python 1.5 packages
  - release python 2.0 in experimental
  - change our packages to test the new implementation
  - fill bug report for all python packages
  - once tested, we'll be ready for woody.

  Any comment, ideas ?

  Thanks.

  Cheers,

-- 
Jérôme Marant <jerome.marant@free.fr>

http://jerome.marant.free.fr


-- 
Jérôme Marant <jerome.marant@free.fr>

http://jerome.marant.free.fr