[csw-maintainers] Python 2.7

[Maciej (Matchek) Bliziński]

2013/7/20 Peter FELECAN <pfelecan at opencsw.org>:
>> 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'm not saying that this is what we should do; but I'm saying that
that's what Debian is doing to share modules between 2.x Python
versions.

>>>>> 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.

Does it? When you have python2.7 looking for modules in the
/opt/csw/lib/python/site-packages (unversioned) directory, and you
make /opt/csw/bin/python2.7 the higher priority alternative, you can
install Python 2.6 and everything will work. You can install Python
2.7 and everything will work too. You've transitioned already, no?

>> - keep 2.6 working
>
> Why is that necessary in the long term?

Our users will migrate from 2.6 into 2.7 at a different point in time
that we do. We must first provide a package catalog in which both 2.6
and 2.7 versions work. Then our users will take their time and update
their installations, and their Python-dependent software. We can use
our release cycle to deprecate Python 2.6, but there still must be an
overlap.

> 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.

Unstable is unstable... but preferably not so unstable that Python
doesn't work any more. If we want to perform a grand rebuild, we have
the beanie catalog specifically for this kind of work.

Maciej