Multirelease effort: Moving to Python 3

[Toshio Kuratomi]

On Thu, Jul 25, 2013 at 06:49:41AM -0400, Bohuslav Kabrda wrote:
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> 
>     <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.
> 
I would be hesitant to do rewriting of the shebang lines.  I suppose that we do
re-byte-compile the .pyc and .pyo now but it seems different to be changing
something that is also source code and human readable automatically.

Some other places to make this same change:  we also have to have people
change anywhere that they use "python" in scripts (for instance, some python
applications ship a shell script that invokes python /path/to/python_file.py
) and our rpm macros should probably also change to use /usr/bin/python2
instead of /usr/bin/python

> 
>     /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.
>
<nod>  And not so unfortunately... setuptools has some pretty iffy code :-/

> 
>     > - 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.
> 
<nod> a main package that doesn't get built triggers an intense dislike for
me but that may be the best thing to do.  I do still think that having two
separate SRPMs is advantageous to packages (I've worked on several packages:
docutils, nose) where the package doesn't build or run correctly on one
version of the interpreter and so it holds back package updates.  dgilmore
pointed out to me yesterday that because python3 is not currently building
for arm, a lot of python packages won't build for arm despite their python2
versions (which is what actual software in the distribution depends on)
building fine.


>     > - 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.
> 
<nod>  True enough :-)

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130725/ebf637e8/attachment.sig>