[csw-maintainers] Python 2.7

[Maciej (Matchek) Bliziński]

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.

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

Maciej