[csw-maintainers] Python 2.7

[Peter FELECAN]

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

> 2013/8/1 Yann Rouillard <yann at pleiades.fr.eu.org>:
>>
>> 2013/8/1 Maciej (Matchek) Bliziński <maciej at opencsw.org>
>>
>>> 2013/7/31 Dagobert Michelsen <dam at opencsw.org>
>>> > I followed the discussion on cross-version modules and the more I think
>>> > about it
>>> > the more I think it would be better to clearly separate modules for
>>> > different
>>> > Python versions. If you already built them with modulations I don't see
>>> > the
>>> > point in putting them all in one package instead of having the old (2.6)
>>> > CSWpy- and the new CSWpy27- and CSWpy33- modules. The only possible
>>> > benefit
>>> > I see is that people who are using 2.6 can pkgutil update and switch to
>>> > 2.7
>>> > after all has been rebuilt. But that can be achieved with a online
>>> > shellscript
>>> > installing CSWpy27- for all CSWpy- modules.
>>>
>>> One argument for keeping the CSWpy- prefix is that we start with one
>>> 2.x version (2.6) and we eventually want to end up with one 2.x
>>> version (2.7). When we go from 2.6 to 2.7, we can introduce the
>>> CSWpy27- packages, but there eventually would only be CSWpy27-
>>> packages and none of CSWpy-. I think that would be just annoyance for
>>> our users. If we can wiggle our way through from 2.6 into 2.7 without
>>> messing around with package names, it's better and smoother for our
>>> users.
>>
>>
>> I don't see this as a major annoyance. After all, users have to clean the
>> obsolete packages on their system, that is not something that is done
>> automatically when a package is dropped from the opencsw catalog.
>>
>> One advantage for having a different prefix is that it will allow users to
>> keep their obsolete 2.6 python module on their system if they want to,
>> whereas if we have only one package CSWpy-, the day we decide to stop
>> shipping python 2.6, they will suddenly disappear.
>> This is not something we officially support, but I think this is nice for
>> users to know that once they installed or compiled something relying on a
>> opencsw library/module, they can be nearly sure it will work as long as they
>> don't remove the package.
>
> We will need to kill Python 2.6 at some point. It probably won't be
> this year, but it eventually has to happen. We should focus on
> discussing when it will happen and how we'll handle it. We will
> probably keep Python 2.6 in one catalog release, and kill it in
> another. Users who want to stick with 2.6 will have the option of
> staying with an old catalog as long as they want.
>
>> I personnally also like consistency. I didn't understand clearly how python
>> 3 modules will be handled. Will they all have a CSWpy33- prefix ? Will we
>> have the same kind of problem during upgrade or is the situation different
>> with python 3 ?
>
> Python 3 is not backward compatible, so modules will live in a
> different place. The main question is whether we will make the module
> installation path specific to the minor version, or only to the major
> version. In other words, will it be /opt/csw/lib/python3.3 or
> something like /opt/csw/share/python3. Debian is doing the latter. We
> haven't really thought about Python 3 handling yet.

Of course is the path as is orthogonal with 2.x path.

>>> I'm curious if anyone will object to my idea to drop the dependency on
>>> the interpreter.
>>
>>
>> The implicit contract is that when you pkgutil -i something, everything will
>> be installed so that it will work properly.
>> That being said, I don't think this is as big problem because:
>>   - if a user manually installs a module, he is supposed to know that a
>> python module needs python and have probably already installed python,
>>   - if a python program need a python module, he also needs for itself the
>> python interpreter so there is no dependency problem.
>>
>> I think this would be a compromise considering the fact that we don't have a
>> dependency system with virtual dependency (where we can say that a package
>> depends on any python interpreter < 3 and >= 2.6)
>
> That's my thinking as well. Unless anyone objects, I'll make it happen soon.

As told before, I object.
-- 
Peter