[csw-maintainers] Python 2.7

[Yann Rouillard]

2013/8/1 Maciej (Matchek) Bliziński <maciej at opencsw.org>
>
>  >> 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.
>

Yes that's something we could say.
We could also let users keep the old version of the package even if they
are using a more recent catalog.

Thanks to having renamed libraries package based on their soname, that's
something that is possible for libraries and I personnally think it's a
good thing.
For example, if someone compiled a binary against libssl0.9.8, they will
not be forced to stick to an old catalog just because of that binary (a
binary that might not even be recompiled against libssl1.0.0).
They will be able to move on to a more recent catalog while keeping the
obsolete libssl0.9.8 package installed.

I would think we could apply the same logic to python packages.


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


Ok, maybe we should try to include python 3 in the reflection to be sure it
doesn't bring some new problem. This way we could define a consistent
policy for Python.

If I understand well, we will prefix all python 3 modules with CSWpy33- our
CSWpy3- ?

It seems for python 3, they tried to define a stable ABI / API subset:
http://www.python.org/dev/peps/pep-0384/

Yann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20130801/2c97a8c6/attachment.html>