On 10/01/2009 10:15 AM, David Malcolm wrote: > Proposal: Python 3 in Fedora 13 > > "Evolutionary, not revolutionary": build a python 3 stack > parallel-installable with the python 2 stack. > First: Overall +1. Note: liberally snipped, throughout. > = Proposal = > Where I would draw the line is on having both python 2 and python 3 > running within the same _process_: the two libraries share most of their > symbol names, but with differing implementations, and the result of > trying to dynamically link the two into the same address space would be > highly unstable. > > As an example, you'd be able to install both mod_python and mod_python3 > rpms, but you wouldn't be able to (sanely) configure httpd to have both > running simultaneously (I guess we should add a run-time warning for > this case) > I don't see any way around this atm but it is something to think about possibilities more. For instance, if we get TurboGears2 ported to python3 while TurboGears1 is still on python2 people will need to run two apache servers (one with python2-mod_wsgi and one with python3-mod_wsgi). > Scoping: > - this work would target Fedora 13. I'd avoid pushing it into F12 > until it's proven safe to do so There's value in pushing the interpreter to F12 as it opens up porting of code from python2 to python3 to more people. I don't think porting applications to python3 in F12 is of great benefit. Pushing libraries back is somewhere in-between. Of course, at some point this is a matter of maintainers doing what's interesting to them. > - the proposal is for python 2 vs python 3. It could be extended to > support having multiple minor-versions of Python as well, but that's a > big extension of the work involved and not something I'm planning to > work on myself. > Unless someone actively wants to work on this right now, I'd like to keep that a separate issue as it just makes matters more confusing. > The more difficult case is when the python module is emitted as part of > the build of a larger module. Some examples: > - the build of "rpm" itself emits an "rpm-python" subpackage. > - Another example is the "postgres" srpm, which emits a > "postgresql-python" subpackage. > There's another case where this exists: upstream plans to do automated translation using a tool like 2to3. This has seemed a bit of a fragile strategy to me but it is recommended by upstream python. > "Naming convention" proposal: > How does this sound: > - an rpm with a "python-" prefix means a python 2 rpm, of the > "default" python 2 minor version (for Fedora this will be the most > recent stable upstream minor release, for EPEL it will be the minor > release of 2 that came with the distro, so 2.4 for EPEL5) > > - an rpm with a "python3-" prefix means a python 3 rpm, of the > "default" python 3 minor version (for Fedora this will be the most > recent stable upstream release) > > What about packages without a "python-" prefix? Proposal: If upstream > has a naming convention for python2 vs python3, use it. Otherwise, add > a "python3-" prefix to make things clear. I'm not sure about the > details here. Examples? > +1 to the basics. There are a lot of details to work out: This seems fine even though it's a bit redundant: python3-pygtk2 and python3-pygpgme. What to do with things that have python in their suffix: gstreamer-python => gstreamer-python3? Or python3-gstreamer? Or python3-gstreamer-python? Most of these are subpackages of existing packages. A cornercase is the gnome-python2 package. These are python bindings to gnome2. gnome-python2 is the upstream name. For python3, do we want python3-gnome-python2, python3-gnome2, python3-gnome-python2 ? > A rough plan for Fedora 13 might be: > - get python3 packaged in a manner compatible with the above > - (persuade /usr/lib/rpm/brp-python-bytecompile to use the correct > python when building rpms containing .py files) > - get rpm bindings working with python3 > - get some useful components working e.g. a web stack: Django, > TurboGears etc (though e.g. Django's py3k support is a long way off > IIRC); ideas? I'm going to go out on a limb and say this is a bigger goal than we'll be able to achieve for F13 but I like it :-) > - solidify packaging guidelines for python 2 vs python 3 once we've > got some experience with the above and hopefully proven the techniques Speaking from FPC experience, +1 to this. > - look at porting major components over to python3 (but probably don't > actually do this for F13; leave python 2 as the critical component, I > suspect): > - yum (rpm) > - anaconda > > However "no plan survives contact with the enemy", we'll see how things > turn out in reality when trying to get a full integrated stack working. > > Future work (F14?) could involve cutting over the major components, so > that the base install would bring in "python3", and "python" would > become optional. Obviously there's a _lot_ to be done before that can > be done sanely. > I'm going to say we'll be beyond F14 when this happens. F14 is roughly a year away and there's a ton of work to do. We may need to have more packagers *and* coders (python and C) to both modify code and maintain the new library packages and bindings. Porting the programs over isn't > = Progress so far = > I've put together a somewhat-working python3 srpm, based on the python > srpm (with lots of FIXMEs added...) It's not yet ready for a formal > package review (I'm working through the various patches, and it's not > yet fully installable in parallel with the python 2 stack), but you can > see the specfile here: > http://people.redhat.com/dmalcolm/python3/python3.spec > and an SRPM here: > http://people.redhat.com/dmalcolm/python3/python3-3.1.1-1.fc13.src.rpm > > After I did this work, I saw that a couple of other people have written > Python 3 srpms for Fedora: > http://ivazquez.fedorapeople.org/packages/python3000/ I was just going to suggest you contact ivazquez :-) he's done a lot of work, both to get a python3 package working and on the update from python2.5 to python2.6. -Toshio
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
