Packaging, supporting both 2.1 and 2.2

[Moshe Zadka <m@moshez.org>]

[please CC me, I'm not on the list]
Hypothetical situation:
Source package: contains foo.py (python module, works with every python
version under the sun) and foo (a script whose first line is 
"import foo"). I want to properly support people who want 2.1 and 2.2.
There are several audiences here:

1. People who want to use "foo"
2. People who want to develop against "foo.py"

Multiplied by

1. People who have python2.1 only 
2. People who have python2.2 only 
3. People who have python2.1 and python2.2

I'm generating a python2.1-foo and python2.2-foo containing foo.py, as
per draft policy. 

Here are alternatives for where to put /usr/bin/foo:

1. in python2.1-foo and python2.2-foo, in /usr/bin/foo, making them conflict
   Pros: easy enough for me.
   Cons: people who develop against foo.py cannot check for 2.1 and 2.2
         compatibility without lots of pain

2. in py2.1-foo and py2.2-foo, as /usr/bin/foo2.{1,2}, manage symlinks
   via alternatives
   Pros: no conflicts
   Cons: high maintainence: every script added to the package must
         be echoed in my postinst/prerm, priority must take into account
         debian default version

3. in py2.1-foo-bin and py.2.2-foo-bin, which depend on an appropriate
   py2.x-foo package, and Provide: Replace: and Conflict: py-foo-bin
   Pros: easy for me, no conflicts of python modules
   Cons: people who want some users to run foo2.1 and some to run foo2.2
         (perhaps foo reads a config file, and the users want to program
         the config file in the appropriate version of python, or as
         in my case, foo keeps state in pickles) cannot

There are, of course, lots of variants possible on these two.
My question is two-fold:

a. Was anyone in this situation? What did you do?
b. Should we document a best current practice in the now-being-written
   developer reference? next version of draft policy?


-- 
To UNSUBSCRIBE, email to debian-python-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org