Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

pure python modules - Python Policy 2.2.3

0 views
Skip to first unread message

Bastian Kleineidam

unread,
Jan 13, 2002, 9:48:10 AM1/13/02
to
Hello Pythoneers,

another version of the dh_purepython script is online at
http://people.debian.org/~calvin/purepython/.

It provides support for Section 2.2.3 of the Python Policy
which adresses version-independent Python modules.

I would be pleased to hear any comments and/or suggestions from you.

In short: to use dh_purepython, your package must have

1) Depends: python
or if you require a specific minimal version X.Y:
Depends: python (>= X.Y)

2) If you use Python Distutils to package your module (which is
recommended), you must have
Build-Depends: pythonX.Y-dev

XXX
It should not be mandatory to build-depend on all pythonX.Y-dev
versions. But you should test your module with multiple Python
versions.

3) installed all .py files into /usr/lib/python/site-packages/.

4) no conflict with future Python versions. It is not supported that
your package works with Python 2.1, but not with 2.2 and above.


A pythonX.Y package must have

1) a postinst script to byte-compile all previously installed
packages who use dh_purepython

2) a prerm script to remove byte-compiled files from all previously
installed packages who use dh_purepyton

I have untested scripts python.postinst and python.prerm for this.


Greetings, Bastian

Torsten Landschoff

unread,
Jan 13, 2002, 4:53:50 PM1/13/02
to
On Sun, Jan 13, 2002 at 09:32:58PM +0100, Matthias Klose wrote:
> > If you ask me, scripts for that should go into the python package so
> > that not every python-xxx package has to carry them itself. Something
> > like /usr/lib/python/new-module $(pkgname) should do all the
> > preprocessing.
>
> the python package may not yet be configured, before a package uses
> it for registration.

If the package module package depends on python (as it has to anyway)
dpkg will configure python before the module in any case (safe
circular dependencies). So this is not an issue. Apart from that,
it would suffice to drop the scripts into the filesystem. If a maintainer
script of the module package can call /usr/bin/python .../compileall.py
directly I see no reason why it should not be able to do this through
a wrapper (which could even remember which source files are compiled
so that python2.3 when available can automatically recompile all
modules).

Am I missing something?

Torsten

0 new messages