[csw-maintainers] Python 2.7

[Peter FELECAN]

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

> 2013/7/20 Peter FELECAN <pfelecan at opencsw.org>:
>> "Maciej (Matchek) Bliziński" <maciej at opencsw.org> writes:
>>
>>> 2013/7/20 Peter FELECAN <pfelecan at opencsw.org>
>>>>
>>>> Look at what Debian has done to make the transition. They are not using
>>>> specific 2.7 packages, the differentiation is 2 versus 3 which is
>>>> understandable as there is an incompatibility between code written for 2
>>>> running in 3.
>>>
>>> I don't think they broke Python 2.6. Or did they? They have a special
>>> mechanism for sharing modules between 2.6 and 2.7.
>>
>> Which is? Anyhow, they don't have the equivalent of CSWpy27-foo. A 2.x
>> package is a 2.x package.
>
> The Debian policy discusses 2.5 vs 2.6, but it's the same discussion.
>
> http://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html
>
> "A common location to share, across Python versions, arch-independent
> files which would otherwise go to the directory of system public
> modules is /usr/share/pyshared."

We can introduce this kind of location if we wish; I'm not being so warm
toward that but why not.

>>>> I would like to be understood that what I'm aiming at is 2 pronged:
>>>>
>>>> 1. minimal investment
>>>> 2. fastest turn around
>>>
>>> With Python 2.6 being expendable?
>>
>> Why do you think so?
>>
>> In my current endeavor, I come to realize that our Python eco-system is
>> brain damaged.
>>
>> What I propose is  not to lobotomize, but to have brain surgery.
>
> A plan that could work, is the following:
>
> - rebuild 2.6 with /opt/csw/bin/python controlled by the alternatives system
> - build 2.7 as you did, with /opt/csw/lib/python/site-packages as an
> extra module search path, and with /opt/csw/bin/python also controlled
> by alternatives

Why alternatives when we wish to make a transition from 2.6 to 2.7?

In my proposition we would have python -> python2 -> python2.7 and
python2.6 is there for those really needing it, which can put in their
scripts #! /opt/csw/bin/python2.6

> - keep using the CSWpy- package name prefix

Alright

> - keep building 2.x modules with Python 2.6 only; never build modules
> with 2.7 and never put them into the
> /opt/csw/lib/python2.7/site-packages directory

Why's that? This precludes a transition.

> - keep Python 3.x completely separate, with CSWpy33- package name prefix

I agree.

> The downside is that we're still using the bad site packages
> directory. The upside is that this scenario meets all the basic
> criteria:

> - keep 2.6 working

Why is that necessary in the long term? Anyhow, I don't get why we
cannot do this in the unstable catalog. Support for 2.7 and associated
eco-system should be a transition criteria from unstable to the next to
next stable / named catalog.

> - easy to do

Sure. The easiest would be to do nothing.

-- 
Peter