Switching to Python 3

[Bohuslav Kabrda]

----- Original Message -----
> On Mon, 2012-08-13 at 03:09 -0400, Bohuslav Kabrda wrote:
> > ----- Original Message -----
> > > On 08/06/2012 04:22 AM, Toshio Kuratomi wrote:
> > > > The only distribution that has switched is arch.  When they did
> > > > there was
> > > > a big uproar about how arch was doing something wrong which
> > > > eventually
> > > > resulted in that PEP.
> > > 
> > > Yeah, we mainly wrote PEP 394 in order to nudge *everyone else*
> > > into
> > > providing a /usr/bin/python2 symlink to help deal with Arch
> > > making
> > > their
> > > bold leap into the unknown (as well as going on record that we
> > > think
> > > switching it *right now* is still a bad idea). There's "bleeding
> > > edge"
> > > and then there's "tap dancing on razor blades in your bare feet"
> > > :P
> > > 
> > > To be honest, I expect that the long term outcome will be that
> > > "/usr/bin/python" becomes solely the preserve of the OS, with all
> > > cross-platform scripts and applications using "/usr/bin/pythonX",
> > > software collections, or language level virtual environments.
> > > 
> > > From an end user perspective, having things mostly compatible
> > > with
> > > both
> > > 2 and 3 should come *before* that symlink gets flipped rather
> > > than
> > > after.
> > > 
> > > Cheers,
> > > Nick.
> > > 
> > 
> > Ok, then I would suggest using Tom Spura's idea about making only
> > python2- and python3- packages (maybe with the virtual python-
> > provides for python2- packages, as Toshio has mentioned). We could
> > target this for F19 and we could also start helping various
> > upstreams
> > with switching to python 3 and see where this will take us. Does
> > that
> > sound good?
> If we're looking at this kind of change (python2-foo and
> python3-foo),
> how about some other prefixes:
>   * python2-debug-foo (or somesuch) for a build of the package
>   against
> the --with-pydebug python2 package
>   * python3-debug-foo
>   * pypy-foo for the package built against PyPy
> 
> FWIW an old idea I had for revamping how we maintain Python packages
> can
> be seen here:
> http://lists.fedoraproject.org/pipermail/python-devel/2010-March/000213.html
> with some further ideas here:
> https://fedoraproject.org/wiki/DaveMalcolm/PythonIdeas
> (you can tell that page is old, it still mentions Unladen Swallow and
> Pynie...)
> 
> I still like the basic idea: introduce a tool that captures the info
> on
> python runtimes for a given release in one place, and use it
> programmatically within specfiles to avoid copy&paste.  Although the
> proposal isn't complete (how to handle exclusions?), I'm still fond
> of
> it.
> 

Personally, I like the idea. As you say, there are still some issues, but I guess we could solve those easily.
There is IMHO one downside of this approach - the complexity. I fear that rpm-pyconfig can be easily taken to such extremes, that we will end up with completely unintelligible specfiles.
As for supporting more runtimes (e.g. Pypy), I would be very careful about that, as it might get us overloaded by tons of issues of different packages with different runtimes.
Here is a wild idea: Would it be possible to create a common site-packages directory for all runtimes? I don't know much about how different runtimes handle bytecode generated by another runtime etc, but it may be worth looking into, if we want to support more runtimes with our packages.

> Another idea would be to use the Software Collections tool seen here:
>   https://fedorahosted.org/SoftwareCollections/
> I known that people within Red Hat have been looking at using that in
> the RHEL context, and some of that is likely to be appropriate for
> EPEL
> too - though AIUI it's a shift in model from one build per src.rpm to
> multiple builds per src.rpm
> 

I've already done my bit of SCL packaging, so here are my 50 cents :)
- How exactly would you apply SCLs in our case? I like the SCL concept (obviously :) ), but if you package e.g. Python 3 as an SCL, then you're going to have a hard time convincing someone to switch their application to it. Maybe packaging all the -debug builds for a single runtime in an SCL might be a good idea? E.g. have one srpm, that would produce optimized build if built out of SCL and debug build if built with SCL.
- SCLs are currently not allowed in Fedora [1] (I'm not sure why, maybe Toshio can explain why FPC chose to forbid them).
- If anyone is interested in an example how things could work out, drop me a line, I can create a simple example.

> Hope this is helpful
> Dave
> 
> _______________________________________________
> python-devel mailing list
> python-devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/python-devel

-- 
Regards,
Bohuslav "Slavek" Kabrda.

[1] https://fedoraproject.org/wiki/Packaging:Guidelines#Software_Collection_Macros