[csw-maintainers] Python 2.7

[Peter FELECAN]

"Maciej (Matchek) Bliziński" <maciej at opencsw.org> writes:

> 2013/7/19 Peter FELECAN <pfelecan at opencsw.org>:
>> Here is what I've done:
>>
>> - created a patch to append /opt/csw/lib/python/site-packages at the end
>>   of the search path for modules
>
> Does it work? When I've suggested this solution, you said it wouldn't.
> If it does, cool!

This is what I experienced when I forced an unversioned tree for 2.7: I
got issues building. With a versioned tree there is no issue and I can
understand why, following the search algorithm.

>> - rebuilt to verify that there is no failure when 2.6 is installed on the
>>   build system
>> - installed 2.7 in parallel with 2.6; there is a conflict on
>>   /opt/csw/bin/python symbolic link but for the moment I ignore this
>
> 2.6 needs to be rebuilt with alternatives. When you're at it, could
> you do it as well?

I'm not sure yet as I don't think that we should use 2.6 alternatively
with 2.7.

I'm still hoping that someone explains me why code written for 2.6
cannot be run by a 2.7 interpreter.

>> - packaging Calibre, which uses construct only available in 2.7, such as
>>   set literals, dictionary comprehensions, is now possible.
>
> Nice.
>
> I gave a little more thought to the CSWpy27- prefix and I think it's
> impossible to avoid it if we ever want to move away from the horrible
> unversioned directory. If we start building modules with the CSWpy27-
> prefix, then at least we have a chance of moving away from the
> unversioned directory and fixing our 2.x Python.

I tend to disagree. What I have in mind is this:

1. 2.7 has /opt/csw/lib/pyhton/site-packages as the last item in
   sys.path; thus packages in it can be executed without issues if they
   are not of "binary" type (still needs a definition for "binary"
   package)

2. 2.6 is repackaged:
   - to remove the /opt/csw/bin/python and
     /opt/csw/share/man/man1/python.1 to avoid conflicts with 2.7; this
     will insure that "binary" modules can be run and those using the
     explicit shebang toward python2.6 are not lost.

3. 2.7 becomes the default python for our distribution, thus new
   packages depends on it and the gar python recipe adapts to this but
   using CSWpy- prefix; I'm hesitating to add that we can obsolete
   CSWpython-xxx by CSWpython27-xxx

4. when version bumps are committed for existing packages, the transition
   is implicit

5. when there is an issue with an existing package, built using 2.6 with
   unversioned tree, we re-spin it; this is why we have Mantis isn't it;
   I think that a Python working group can be created to take into
   account packages for retired maintainers.

What do you think?
-- 
Peter