[csw-maintainers] Automatically excluding .pyc files

[Maciej (Matchek) Blizinski]

No dia 14 de Outubro de 2010 03:24, Ben Walton <bwalton at opencsw.org> escreveu:
> 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?

I agree with Ben.  The Python file placement in CSWpython predates my
involvement in the project, so I don't have any opinion on the
problems that were happening in the past.  I have some knowledge about
what is the standard way of packaging Python, and what we're doing is
not it.

Each Python version requires the rebuild of all the modules.  Here's a
sketch of what packages could be named like:

CSWpython (symlink only)
CSWpython-devel (one devel package pointing at the newest Python)
CSWpython26 (specific version of the interpreter)
CSWpython27 (specific version of the interpreter)
CSWpython31 (specific version of the interpreter)
CSWlibpython2_5_1_0 (libpython for 2.5)
CSWlibpython2_6_1_0 (libpython for 2.6)
CSWpy26-foo (Python module for 2.6)
CSWpy27-foo (Python module for 2.7)
CSWpy31-foo (Python module for 3.1)