Hello, guys.  I am looking for feedback on the topic which I am going to
lay out.  First, sys.path:

-------------------
# python2.4
>>> import sys
>>> sys.path
['', '/home/rudd-o', '/usr/lib64/python24.zip', '/usr/lib64/python2.4',
'/usr/lib64/python2.4/plat-linux2', '/usr/lib64/python2.4/lib-tk',
'/usr/lib64/python2.4/lib-dynload',
'/usr/lib64/python2.4/site-packages',
'/usr/lib64/python2.4/site-packages/Numeric',
'/usr/lib64/python2.4/site-packages/PIL',
'/usr/lib64/python2.4/site-packages/gtk-2.0',
'/usr/lib/python2.4/site-packages', '/usr/lib64/site-python',
'/usr/lib/site-python']
------------------

Now: Currently, bdist_rpm target builds RPMs that install to
/usr/lib(64)/python2.X/site-packages/.  This is wasteful and inefficient
in the case of pure python modules for the following reasons:

1. It necessitates a rebuild of the python modules for at least 2
architectures -- 64-bit and 32-bit, since they go to different
directories.  Worst part is, the packages themselves are
indistinguishable by name (they are built as Noarch in all
architectures) so a package built in 64bit cannot function in 32bit BUT
it is *installable* by RPM.
2. It necessitates a rebuild for every python minor version out there,
2.4, 2.5, 2.6.  This is also problematic because packages need to be
rebuilt for every distribution release out there, instead of being able
to build a single RPM that works across distro releases (or, the holy
grail, across distros altogether).

Now, I have familiarized myself with distutils enough that I can make a
quick patch that

- detects if the package is a pure python module
- ensures that the install-purelib directive in the [install] section of
setup.cfg is absent

and if both conditions are present, then the package is automatically
installed into /usr/lib/site-python.

The benefits are clear:

- only a single RPM needs to be built across distro versions and
architectures
- it enables cheese shop packages to be quickly built on a machine and
then installed in another
- it eliminates the need for the tedious process of writing custom spec
files
- packages built this way can be loaded and run by virtually all 2.x
python interpreters out there right now
- it would be possible to even build python RPMs that work across
distributions

This patch is no more than a two-liner, and I am looking for input, to
see if someone agrees, or not, to flesh out any pitfalls before going
in.  So do your best and provide sensible reasons why I should not do
this, or else I will do it and submit a patch.

Clock's ticking.