[csw-maintainers] Automatically excluding .pyc files

[Ben Walton]

Excerpts from Philip Brown's message of Wed Oct 13 13:39:50 -0400 2010:

> wait what?

> we've been through this a few times. python files need to be
> compiled to a single, consistent place. Altering the dest with
> numerical revisions, has caused problems in the past.

Ok, I'm looking at libxslt python handling right now and it goes to
great lengths to find a version numbered python site-packages and
includes directory.

Looking at my debian box here, I have _only_ version suffixed
directories...there is no generic /usr/lib/python.

$ ls -ld python*
drwxr-xr-x 21 root root 20480 2010-01-23 08:05 python2.5
drwxr-xr-x 23 root root 20480 2010-04-30 07:24 python2.6
drwxr-xr-x 28 root root 20480 2010-09-29 07:35 python3.1

Looking at current9x, we have /opt/csw/include/python (mostly empty)
and /opt/csw/include/python2.6 (the expected files).  We then have
/opt/csw/lib/python2.6 (mostly empty) and /opt/csw/lib/python
(expected set of files).  This is internally inconsistent. :(

So, the question is, why are we _not_ shipping .py files in a version
specific site-packages area?  Is this the general aversion to shipping
multiple python packages to support multiple version simultaneously?

Given the landscape that I see out there, it looks to be logical to
ship a functional python2.5 (maybe not now), python2.6, python3.x, etc
that can co-exist.  If we shipped a python 2.7 (for example only),
we'd have lib/python2.7, include/python2.7 and bin/python2.7
(alternatives could provide the bin/python).

This should make version upgrades of python less problematic for
modules that are built against $current_version.  Similar to what
we're aiming to do with libraries, we could do with interpreters...

Thoughts?

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302