[EPEL-devel] Python 3 discussion

[Bohuslav Kabrda]

----- Original Message -----
<snip>
> >> What I still don't understand is what this looks like on the user end, how
> >> do
> >> they go from 34 to 35?  For app users (#!/usr/bin/python3), it seems like
> >> this
> >> should be as automatic as possible.  So shouldn't they still use
> >> /usr/bin/python3 rather than /usr/bin/python3X so they get updated
> >> automatically?
> >
> > I think applications should use /usr/bin/python3.4 (at least packaged
> > applications). Otherwise we could theoretically end up in a situation
> > where /usr/bin/python3 is owned by python35, but the application RPM still
> > has python34- dependencies and thus the app doesn't work.
> >
> > I think this is actually one of the reasons why I thought it makes sense to
> > keep both python34 and python35 living together in the state where
> > python35 is the main python3 (having the default macros and owning
> > /usr/bin/python3) and python34 is the "other". Let's take this example:
> > - there's an application "foo" written in python, which requires "six"
> > - it doesn't make sense to build the application for both python34 and
> > python35, since it's an application, not a library
> > - this means it doesn't make sense for package maintainer to introduce the
> > %python3_{other or next}* macros to the specfile, maintainer just wants to
> > build with "the python3"
> > - so this means that we should do this:
> > -- python 3.5 is released, we build it in EPEL and turn with_python3_other
> > to 1 in python3-pkgversion-macros
> > -- then there's a period when python34 and python35 coexist and python34 is
> > "the main python" - in this period, *libraries* are rebuilt to provide
> > both python34- and python35- subpackages
> > -- python34 and python35 are switched (the default macros now point to 35
> > and it also owns /usr/bin/python3 now)
> > -- then there's a period when python34 and python35 coexist and python35 is
> > "the main python" - in this period, *applications* are rebuilt for
> > python35 (may take some time, there will likely be a period when there are
> > some apps on python34 and some already on python35)
> > -- when all applications are rebuilt for 35, with_python3_other is set to 0
> > and we now have just python35 and it's the "main" python3
> >
> > Does this make sense or am I missing something? I'd need to do some minor
> > changes+explanations to my proposal to accomodate this, but I still think
> > it makes sense.
> 
> Okay, a pure python app (named "app") that used /usr/bin/python3.4,
> would have to get rebuilt, version/release would get bumped, and pull in
> 3.5.
> 
> But if it used /usr/bin/python3, there wouldn't be a need for a rebuild.
>   It would require /usr/bin/python3, and the installed python34 would
> always provide that, so it wouldn't migrate.  Now I get it.
> 
> Had to work that one out.

Good. I'll try to update my proposal to explain it better (if someone could suggest how to explain this nicely, I'd be happy to accept their wording ;))

> >> What about all of the old python34 packages left on their systems after
> >> retirement?  Is there some way they can get cleaned up automatically?
> >
> > I'm not sure about that... and I'm also not sure we want to do that, people
> > may still want to keep these around for their own non-system applications
> > to migrate.
> >
> > Thanks a lot for this discussion,
> > Slavek
> >
> >> --
> >> Orion Poplawski
> >> Technical Manager                     303-415-9701 x222
> >> NWRA, Boulder/CoRA Office             FAX: 303-415-9702
> >> 3380 Mitchell Lane                       orion at nwra.com
> >> Boulder, CO 80301                   http://www.nwra.com
> --
> Orion Poplawski
> Technical Manager                     303-415-9701 x222
> NWRA/CoRA Division                    FAX: 303-415-9702
> 3380 Mitchell Lane                  orion at cora.nwra.com
> Boulder, CO 80301              http://www.cora.nwra.com


Slavek