Multirelease effort: Moving to Python 3

[Bohuslav Kabrda]

----- Original Message -----

> On Jul 25, 2013 12:13 AM, "Bohuslav Kabrda" < bkabrda at redhat.com > wrote:
> >
> > ----- Original Message -----
> > > Since Python upstream really cares about these things, I started a
> > > discussion
> > > about this on their mailing list [1]. So far, it seems that people prefer
> > > my
> > > mental model, but this is judging from just 4 answers, 2 of which
> > > mentioned
> > > this. So let's wait and see.
> > > BTW, if Python 2 and Python 3 were different languages, then IMO it
> > > wouldn't
> > > make sense to point /usr/bin/python to Python 3, while upstream plans to
> > > actually give the recommendation to do so sometime in the future.
> > >
> >
> > So, judging from what upstream has recommended (and how they will modify
> > pep 394), we should:
> > - Mandate usage of /usr/bin/python2 and prohibit usage of /usr/bin/python
> > (I think this can be done automatically in %__os_install_post, or
> > somewhere similar) - we should probably do that ASAP

> <nod>. Which means patching in a bunch of packages. For os_install_post
> modification you're talking about a check that fails the build if
> /usr/bin/python is used? I note that upstream envisions some cases where
> /usr/bin/python is correct but I don't recall any package where we'd have
> invoked that clause (the case is when the code will run on either python2 or
> on python3)
I meant something that would actually rewrite the lines, even though that may be very expensive to run for every build... Failing the build is another option, yes. I'll try to have a look at how these would be implemented. 

> /me goes to the upstream thread to ask Nick what distutils/setuptools/etc do
> when they rewrite shebang lines.
Hmm, patching setuptools to do this for us sounds interesting, although not everything that has /usr/bin/python uses setuptools for build, unfortunately. 

> > - Rename python to python2 and add "Provides: python" for the time being
> > (the similar should probably be done for all python packages to keep
> > things consistent) - we can do this for F21

> Renaming other packages gets problematic. See the previous discussion on
> python-devel at lists.fp.o that tomspur championed. (This was one of the items
> I was hoping could be discussed at flock) You wouldn't expect to report bugs
> for the python3-foo library against the python2-foo package for instance.
> One possibility that we talked about was to stop shipping python3 packages
> as subpackages of the python2 modules.
Yep, I remember. I'm thinking about this (hope I'm not repeating anyone's idea from before): 
What if we use one python-foo.srpm to produce two python2-foo.rpm and python3-foo.rpm, but not produce python-foo.rpm? Assuming that python2-foo has Provides: python-foo, I think that pretty much achieves what we want - unless I'm missing something. The only glitch I can see is that we would need to tell users that they need to report all bugs for python-foo component. But they can do the mapping from python3-foo to python-foo now, so it shouldn't hurt so much, IMO. 

> > - Somewhere in the future switch "Provides: python" to python3 stuff and
> > possibly /usr/bin/python to point to python3, according to upstream
> > recommendation (2015?) to keep consistent across multiple platforms as
> > much as possible.
> >

> Rather than 2015 I'd tie it to when upstream switches the recommendation in
> pep 394.
That is what I meant :) 2015 was just a wild guess of when that might happen. 

> -Toshio
-- 
Regards, 
Bohuslav "Slavek" Kabrda. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130725/d670c767/attachment.html>