[csw-maintainers] Python 2.7

Yann Rouillard yann at pleiades.fr.eu.org
Thu Aug 1 09:21:28 CEST 2013

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.

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 ?

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


> Maciej
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20130801/a83a48c9/attachment.html>

More information about the maintainers mailing list