Re: Switching to Python 3
- 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? > -- > Nick Coghlan > Red Hat Infrastructure Engineering & Development, Brisbane > ___ > python-devel mailing list > [email protected] > https://admin.fedoraproject.org/mailman/listinfo/python-devel -- Regards, Bohuslav "Slavek" Kabrda. ___ python-devel mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: Switching to Python 3
On 08/13/2012 05:09 PM, Bohuslav Kabrda wrote: > 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? That sounds pretty sensible to me. One sticking point may be upstreams that still want to support RHEL 5, since supporting both 2.4 and 3.x out of the same code base is fairly painful (whereas 2.4-2.7 is pretty easy if you don't mind missing out on the shiny new features in later versions and 2.6+ and 3.2+ is fairly straightforward with the aid of the six project and/or some compatibility modules). However, that problem can be addressed on a case-by-case basis as it comes up. Cheers, Nick. -- Nick Coghlan Red Hat Infrastructure Engineering & Development, Brisbane ___ python-devel mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: Switching to Python 3
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. 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 Hope this is helpful Dave ___ python-devel mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: Switching to Python 3
On Mon, 2012-08-13 at 20:53 -0400, David Malcolm wrote: > 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 The "gitweb" URLs in that mail are stale as fedorapeople.org is now using cgit; see: http://fedorapeople.org/cgit/dmalcolm/public_git/rpm-pyconfig.git/tree/ ___ python-devel mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: Switching to Python 3
- 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 > [email protected] > https://admin.fedoraproject.org/mailman/listinfo/python-devel -- Regards, Bohuslav "Slavek" Kabrda. [1] https://fedoraproject.org/wiki/Packaging:Guidelines#Software_Collection_Macros ___ python-devel mailing list [email protected] https://admin
