The best way to package a Python module?

[Ben Finney]

Jean-Paul Calderone <exarkun at divmod.com> writes:

> >What has changed is that the tools in common use for Debian
> >packaging of Python libraries have taken on the role of generating
> >those per-version copies at install time.
> 
> exarkun at boson:~$ ls -l /usr/lib/python2.{4,5}/site-packages/sqlite/main.py
> lrwxrwxrwx 1 root root 63 2007-12-27 15:29 /usr/lib/python2.4/site-packages/sqlite/main.py -> /usr/share/pycentral/python-sqlite/site-packages/sqlite/main.py
> lrwxrwxrwx 1 root root 63 2007-12-27 15:29 /usr/lib/python2.5/site-packages/sqlite/main.py -> /usr/share/pycentral/python-sqlite/site-packages/sqlite/main.py
> exarkun at boson:~$ 
> 
> That doesn't seem to agree with your statement.  Am I missing something?

You are missing an inspection of the contents of the actual package
file. The package file itself contains only a single copy of the
Python module (at /usr/share/pycentral/site-packages/sqlite/main.py).

What you see there on your filesystem was created at install time; the
installation tool figures out, at install time, which Python versions
need to be supported on this particular system, and creates those
symlinks.

Thus, the change that's occurred is that the user doesn't need to
choose between "Python SQLite library for Python 2.4" and "Python
SQLite library for Python 2.5".

There is no longer a separation at the package level by Python
version, so the user merely needs to choose (given your example) the
single "Python SQLite library", and the install process takes care of
setting it up for all supported versions of Python on the system.

-- 
 \       “[Freedom of speech] isn't something somebody else gives you. |
  `\           That's something you give to yourself.” —_Hocus Pocus_, |
_o__)                                                    Kurt Vonnegut |
Ben Finney