Re: Proposal: Python 3 in Fedora 13
On Sat, 2009-10-03 at 22:09 +0200, yersinia wrote: On Thu, Oct 1, 2009 at 7:15 PM, David Malcolm dmalc...@redhat.com wrote: [snip] $ rpm -qf /usr/lib/python2.*/site-packages/* | grep -v is not owned | SIA, this is off of topic , i am sure. BUT, it is very strange that could be exists, perhaps, some file or directory not owned by someone. Isn't it ? FWIW I've done a lot of packaging experimentation on that system, and brute-force copying of .py files into place, so there's a fair amount of cruft lurking about on my system. That's why I had that in the shell pipeline I gave. (But yes, this is heading off-topic) sort | uniq | xargs rpm -q --qf %{NAME}-%{VERSION}-%{RELEASE} %{SOURCERPM}\n | sed -es/.src.rpm// | squeal -f table col0, col1 from - where col0 != col1 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Thu, Oct 1, 2009 at 7:15 PM, David Malcolm dmalc...@redhat.com wrote: Proposal: Python 3 in Fedora 13 Evolutionary, not revolutionary: build a python 3 stack parallel-installable with the python 2 stack. = High-level summary = - Python 3.0 was released almost 10 months ago, on 2008-12-03, and the latest release of the 3.* branch is 3.1.1, released on 2009-08-17. - Other distros have python 3, though not necessarily with anything on top resembling the full python 2 stack. - We have a working, valuable python 2 stack, which is used by critical system components (yum and anaconda): we must not destabilize the python 2 stack. - Python 3 is sufficiently different from python 2 that we need them to be independent software stacks. - I plan to spend a large chunk of my $DAYJOB over the next few months trying to build a useful Python 3 stack for Fedora 13, for some definition of useful (help will be appreciated!) - I don't want to add extra work for package maintainers: if you maintain an SRPM of a python 2 module that's working for you, you shouldn't feel obligated to own a separate SRPM for python 3. If someone has a need for the module on python 3, they can take on that work. = Background = Python 3 is intended by upstream to be the future of Python, but we have many critical components that use Python 2. Python 2 and Python 3 are sufficiently different that we need both (try writing print in each). Python 2 will be around for a long time. An interesting summary of Python 3 adoption can be seen here: http://renesd.blogspot.com/2009/09/py3kpython3-more-than-one-year-on-096.html An earlier proposal about python 3 in Fedora is here: https://www.redhat.com/archives/fedora-devel-list/2008-May/msg02417.html Going forward, I will have plenty of time to spend, as part of my dayjob, on Python in Fedora [1] = Proposal = I want to get python 3 into Fedora, but I don't want to break yum or anaconda (or anything else, for that matter!) How to do this? I propose that Fedora shall have separate, parallel-installable Python 2 and Python 3 stacks. I believe we can get things to the point where on a Fedora box you'd be able to install both stacks, and have some processes running python 2 code, and some running python 3, simultaneously. 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) Scoping: - this work would target Fedora 13. I'd avoid pushing it into F12 until it's proven safe to do so - 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. = Details = We should split python 2 and python 3 at the source RPM level, where possible. The easy case is when upstream release separate tarballs for the python 2 and python 3 versions of code. For example, given package python-foo in packaging CVS, there would be a separate python3-foo for the python 3 version. There would be no expectation that the two would need to upgrade in lock-step. (The two SRPMS could have different maintainers within Fedora: the packager of a python 2 module might not yet have any interest in python 3) 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. In a quick attempt at seeing other examples, on my laptop (F11), here are the packages installed that provide python modules where the package name differs from the srpm name: $ rpm -qf /usr/lib/python2.*/site-packages/* | grep -v is not owned | SIA, this is off of topic , i am sure. BUT, it is very strange that could be exists, perhaps, some file or directory not owned by someone. Isn't it ? sort | uniq | xargs rpm -q --qf %{NAME}-%{VERSION}-%{RELEASE} %{SOURCERPM}\n | sed -es/.src.rpm// | squeal -f table col0, col1 from - where col0 != col1 col0| col1| +--+ at-spi-python-1.26.0-1.fc11| at-spi-1.26.0-1.fc11| audit-libs-python-1.7.13-1.fc11| audit-1.7.13-1.fc11| cracklib-python-2.8.13-4| cracklib-2.8.13-4|
Re: Proposal: Python 3 in Fedora 13
On Thu, Oct 1, 2009 at 19:15, David Malcolm dmalc...@redhat.com wrote: - We have a working, valuable python 2 stack, which is used by critical system components (yum and anaconda): we must not destabilize the python 2 stack. Do we have an idea how far our stack is from working on python3 ? And how far all the rest of python packages is? I think at one point the decision to switch to python3 has do be done and some packages will be left behind (at least for a while). It is just a question when the switch will happen. A parallel python3 stack now would mostly be usable for people using python3 for work and for these a separate repo would be enough, they probably will need this for RHEL/CentOS too. Cheers, Christof -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
Le 02/10/2009 09:46, Christof Damian a écrit : Do we have an idea how far our stack is from working on python3 ? And how far all the rest of python packages is? Not much, there are few external modules working though the list is slowly growing (pyqt4, openCV etc, libxml...). Here are some python3 modules hosted on PyPI http://pypi.python.org/pypi?:action=browsec=533show=all I think at one point the decision to switch to python3 has do be done and some packages will be left behind (at least for a while). It is just a question when the switch will happen. There should be no discussion of switching to python3 as default interpreter before the upcoming python 2.7. Python 2.7 is planned to the last offspring of python2.x and to further reduce the gap between python2 and python3. A parallel python3 stack now would mostly be usable for people using python3 for work and for these a separate repo would be enough, they probably will need this for RHEL/CentOS too. It won't. *BSD, fellow GNU/Linux distro like Debian, Mandriva, Ubuntu even macports are able to ship multiples python stacks and we (Fedora) are not ? Isn't Fedora supposed to lead ? Since Python is parallel installable by design, our main issues are to deal with packaging guidelines (naming, possible conflicts, etc ...) and considering porting our own python modules and/or fixing them to ease the port. Though a separate repo would help to identify and fix possible conflicts, we should be able to provide a minimal python3 stack for F-13 (and maybe F-12 through updates) and eventually few blessed third-party modules. After all, others are already shipping it or will ship it in their next release. Besides, that would encourage python modules maintainers to port and test their modules on python3. Besides, the longer we wait, the harder/longer the transition will be. H. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
Taking a step back to look at a broader picture, what is determined here might be helpful when migrating other packages such as : perl6 php6 java2 ( or whatever Sunacle calls it officially ) ruby2 Although none of those are as central to the operation of Fedora as python, they all will suffer migration pains, and likely will require some type of parallel install of old and new versions, as well as migration of requires and provides. perl 6 is in F12 as I recall, under a pseudonym. Keeping python2 around ( and perl5, etc. ) named that way and not moving to compat-python2 or compat-perl5 may not be a bad thing. Using compat-* as a naming convention does signal don't use this unless you have to however is it really required ? I know, it may be too early to think about when python2 moves to a compat-* status, but as slowly as the migration to python3 is going, there may be a need for parallel installs of python2, python3, and python4. I know, ick, but possible. It might be best to keep the major version number as part of the package name(s) permanent. -- Charles Dostale -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
Le Ven 2 octobre 2009 17:07, chasd a écrit : java2 ( or whatever Sunacle calls it officially ) We use our own naming for this because SUN changed its mind too often on how it should be named. So now we ignore upstream naming and use our own consistent one. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Fri, Oct 2, 2009 at 17:07, chasd ch...@silveroaks.com wrote: Taking a step back to look at a broader picture, what is determined here might be helpful when migrating other packages such as : perl6 php6 java2 ( or whatever Sunacle calls it officially ) ruby2 the good thing is that they then can end up in EPEL too. This would make a lot of PHP users happy, which are currently living in the RHEL PHP stone age. (or use some other repo) Christof -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
perl6 That's already a Fedora 12 feature. https://fedoraproject.org/wiki/Features/Rakudo_Perl_6 -- Mathieu Bridon (bochecha) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Fri, Oct 2, 2009 at 9:20 AM, Haïkel Guémar karlthe...@gmail.com wrote: *BSD, fellow GNU/Linux distro like Debian [...] are able to ship multiples python stacks In Debian's case of course there are actually *two* separate Python systems ;) http://wiki.debian.org/DebianPythonFAQ I didn't understand either and was quite confused trying to debug one of my Python applications on Debian, but if they're useful we might consider adopting one of them rather than reinventing another parallel install system. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Thu, 2009-10-01 at 13:15 -0400, David Malcolm wrote: [snip] (replying to self, with some archive links) An earlier proposal about python 3 in Fedora is here: https://www.redhat.com/archives/fedora-devel-list/2008-May/msg02417.html ...which was the Let's make a plan for python3.0 in Fedora 10+ thread. FWIW, looking back in the logs there was also: python-2.6 and python-3.x ( https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00085.html ) and further back: The looming Python 3(000) monster https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00379.html [snip] -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On 10/02/2009 08:48 AM, Colin Walters wrote: On Fri, Oct 2, 2009 at 9:20 AM, Haïkel Guémar karlthe...@gmail.com wrote: *BSD, fellow GNU/Linux distro like Debian [...] are able to ship multiples python stacks In Debian's case of course there are actually *two* separate Python systems ;) http://wiki.debian.org/DebianPythonFAQ I didn't understand either and was quite confused trying to debug one of my Python applications on Debian, but if they're useful we might consider adopting one of them rather than reinventing another parallel install system. I brought up Debian's parallel install system before (I believe the last time python24 python2 python3 came up) and someone did a quick anaysis and said it wasn't a good idea. Beyond that, I know that it won't work for managing python2 and python3. The languages have diverged too much. It can manage things like python24 python25 python26 but that's not at issue right now. -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Thu, Oct 1, 2009 at 1:15 PM, David Malcolm dmalc...@redhat.com wrote: Proposal: Python 3 in Fedora 13 [snip] - I don't want to add extra work for package maintainers: if you maintain an SRPM of a python 2 module that's working for you, you shouldn't feel obligated to own a separate SRPM for python 3. If someone has a need for the module on python 3, they can take on that work. In the case of a Python binding produced as part of a larger package, though, how do we go about doing this? Seems like the sensible way is to have the person wanting to do the work sign up as co-maintainer, and take charge of the Rawhide branch of the package. Care must then be taken to make sure the F-12 and rawhide packages don't diverge much, apart from any Python 3 fixes required. Any fix that is 2.x-compatible should probably be merged to the F-12 build as well, and upstreamed. 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. We could then %prep the rpm build for each of the above so that the python 3 support is built as a parallel component of the build, independently of the python 2 support e.g. by copying the python2 support into a separate dir, then applying a patch as necessary (and somehow wiring up the configuration/make so it builds both...) The caveat here is that I haven't tried actually doing this yet for any of these packages. Issues with this approach: - I don't yet know if autoconfiguration will work well with both -devel packages installed - It will probably involve actually doing the porting work for each package (yay, we get to be leaders!) - Whoever does this for a package needs to work closely with the upstream for that package Since yum is available during build, this would work (but is fugly): - build as normal - push out python2 files to buildroot - after everything else is done, yum remove python-devel yum install python3-devel - build python3 modules Regards, -- Michel Alexandre Salim -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On 10/02/2009 02:28 PM, Michel Alexandre Salim wrote: Since yum is available during build, this would work (but is fugly): - build as normal - push out python2 files to buildroot - after everything else is done, yum remove python-devel yum install python3-devel - build python3 modules There used to be locking issues with running from inside of the spec. Don't know if that still applies. We may also be denying network access to processes running inside of the buildroot. (AFAIK, the buildroot is constructed from outside. Then we chroot into it and run the build). Even if those aren't problems, we're probably better off going with the traditional, build once, move build files to a new location, build a second time. install both sets of built files route. (For instance, vim-minimal and vim-enhanced) -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Fri, Oct 2, 2009 at 8:19 PM, Toshio Kuratomi a.bad...@gmail.com wrote: I brought up Debian's parallel install system before (I believe the last time python24 python2 python3 came up) and someone did a quick anaysis and said it wasn't a good idea. Fair enough, just wanted to be sure it was at least looked at. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Thu, Oct 01, 2009 at 01:15:09PM -0400, David Malcolm wrote: Scoping: - this work would target Fedora 13. I'd avoid pushing it into F12 until it's proven safe to do so I'm going to think on the overall proposal more, but I very very very much wish this sentence said I will not push this into F12 at all. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Oct 1, 2009, at 10:59, Josh Boyer jwbo...@gmail.com wrote: On Thu, Oct 01, 2009 at 01:15:09PM -0400, David Malcolm wrote: Scoping: - this work would target Fedora 13. I'd avoid pushing it into F12 until it's proven safe to do so I'm going to think on the overall proposal more, but I very very very much wish this sentence said I will not push this into F12 at all. josh Ditto. This is not something you would push as an update to a released product. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
Once upon a time, Josh Boyer jwbo...@gmail.com said: On Thu, Oct 01, 2009 at 01:15:09PM -0400, David Malcolm wrote: Scoping: - this work would target Fedora 13. I'd avoid pushing it into F12 until it's proven safe to do so I'm going to think on the overall proposal more, but I very very very much wish this sentence said I will not push this into F12 at all. Yeah, we seem to have too much churn going with some things as it is during a release. What possible reason would there be to push a major new component into an existing release? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On 10/01/2009 11:11 AM, Jesse Keating wrote: On Oct 1, 2009, at 10:59, Josh Boyer jwbo...@gmail.com wrote: On Thu, Oct 01, 2009 at 01:15:09PM -0400, David Malcolm wrote: Scoping: - this work would target Fedora 13. I'd avoid pushing it into F12 until it's proven safe to do so I'm going to think on the overall proposal more, but I very very very much wish this sentence said I will not push this into F12 at all. josh Ditto. This is not something you would push as an update to a released product. I disagree. The proposal is really treating python3 as a new language. We can and do push such things into a released Fedora. -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Thu, 2009-10-01 at 13:07 -0500, Chris Adams wrote: Once upon a time, Josh Boyer jwbo...@gmail.com said: On Thu, Oct 01, 2009 at 01:15:09PM -0400, David Malcolm wrote: Scoping: - this work would target Fedora 13. I'd avoid pushing it into F12 until it's proven safe to do so I'm going to think on the overall proposal more, but I very very very much wish this sentence said I will not push this into F12 at all. Yeah, we seem to have too much churn going with some things as it is during a release. What possible reason would there be to push a major new component into an existing release? Agreed. This part of my post was clumsy. I think what I meant to say was that I'd want to veto anyone wanting to push it into F12, that they'd have a significant burden of proof of safety before such an action could occur. I don't have any interest in such a backport. Sorry Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Thu, 2009-10-01 at 11:23 -0700, Toshio Kuratomi wrote: On 10/01/2009 11:11 AM, Jesse Keating wrote: On Oct 1, 2009, at 10:59, Josh Boyer jwbo...@gmail.com wrote: On Thu, Oct 01, 2009 at 01:15:09PM -0400, David Malcolm wrote: Scoping: - this work would target Fedora 13. I'd avoid pushing it into F12 until it's proven safe to do so I'm going to think on the overall proposal more, but I very very very much wish this sentence said I will not push this into F12 at all. josh Ditto. This is not something you would push as an update to a released product. I disagree. The proposal is really treating python3 as a new language. We can and do push such things into a released Fedora. Treating it as a new language is the intent, and I'll make every effort to keep them separated. In theory there wouldn't be any problems. However if I screw up and somehow cross the streams, I run the risk of breaking _lots_ of things; yum is the most obvious victim in the critical path. Obviously I don't want to do that. I'm not volunteering to put it into F12. I think that anyone wanting to push it into F12 needs to sign up for a lot of testing (brainstorming some testcases: can you still compile and build external modules with both 2 and 3 -devel subpackages installed? does every configure script pick up the correct version? etc) Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Thu, 1 Oct 2009, David Malcolm wrote: Treating it as a new language is the intent, and I'll make every effort to keep them separated. In theory there wouldn't be any problems. However if I screw up and somehow cross the streams, I run the risk of breaking _lots_ of things; yum is the most obvious victim in the critical path. Obviously I don't want to do that. I'm not volunteering to put it into F12. I think that anyone wanting to push it into F12 needs to sign up for a lot of testing (brainstorming some testcases: can you still compile and build external modules with both 2 and 3 -devel subpackages installed? does every configure script pick up the correct version? etc) Now- perhaps a repo with your package in it that someone could consume on f12 would be a straightforward goal... if you need extra space on fedorapeople.org for this - let me know. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Thu, Oct 1, 2009 at 2:39 PM, David Malcolm dmalc...@redhat.com wrote: I'm not volunteering to put it into F12. I think that anyone wanting to push it into F12 needs to sign up for a lot of testing (brainstorming some testcases: can you still compile and build external modules with both 2 and 3 -devel subpackages installed? does every configure script pick up the correct version? etc) Which brings up a useful point in that the critical path has two components; the closure of their Requires, and the closure of their BuildRequires. However - this still seems like low risk to me because the builders only build with what's specified in BuildRequires, so you'd have to have quite a contortion to get python3-devel in there. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
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
Re: Proposal: Python 3 in Fedora 13
Jesse Keating wrote: Ditto. This is not something you would push as an update to a released product. I don't see why a parallel-installable python3/python3000 would cause any problems as an update. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Thu, 2009-10-01 at 23:21 +0200, Kevin Kofler wrote: Jesse Keating wrote: Ditto. This is not something you would push as an update to a released product. I don't see why a parallel-installable python3/python3000 would cause any problems as an update. Kevin Kofler The potential to disrupt the regular python, which is critically important to Fedora, makes me very wary of doing something like this on a release that is supposed to be and stay stable. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
Once upon a time, Kevin Kofler kevin.kof...@chello.at said: Jesse Keating wrote: Ditto. This is not something you would push as an update to a released product. I don't see why a parallel-installable python3/python3000 would cause any problems as an update. Are you able to guarantee that it will in no way interfere with python2 (including in the build root)? Major changes like that during a release are what get Fedora considered a rolling beta quality distribution. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Thu, 2009-10-01 at 12:17 -0700, Toshio Kuratomi wrote: 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. [likewise snipped lots of stuff] 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: [snip the details] Thanks. Given that, I went ahead and created a Feature page for this: https://fedoraproject.org/wiki/Features/Python3F13 So far it's mostly just a restatement of my post, though I've started fleshing out some sections e.g. how to test. I've assumed the naming convention from my post python3 for the srpm, and for the symlink to the binary. Feel free to dive in and edit. I marked myself as owner of the feature as I know I'm going to be able to devote a big chunk of time to this. Hope that's OK. We now have 3 competing srpms for Python 3: (i) the one from ivazquez: http://ivazquez.fedorapeople.org/packages/python3000/ (python3000) (ii) the one by Andrew McNabb: https://bugzilla.redhat.com/show_bug.cgi?id=526126 (named python3) (iii) and the one I did, also named python3: 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 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. I'm assuming ivazquez is seeing these emails (I _think_ he said he'd seen it on IRC earlier today), and I added a link to my email to the review bug above so hopefully Andrew is seeing this. I hope to have a look at the commonality/differences between the 3 efforts tomorrow. I think python3 is a better name (if nothing else, it's shorter to type!). I'd like it if the eventually python 3 specfile could resemble the python 2 specfile so that we can meaningfully look at the textual diffs between them (but it may be necessary to clean up the python specfile to achieve this! I'll try to have a look at the merge-review) Thanks for the feedback; hope this all sounds sane Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 David Malcolm wrote: 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) (we could extend this to have specific minor-releases (e.g. use python24- for a python 2.4 stack, in case some brave soul wants to get zope/plone running. But may be better to try to fix the zope/2.6 incompatibility at that point (caveat: haven't looked at the details of the issue). I don't intend to work on such versions)) 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? There have been various discussions upstream about what to call the python 3 binary. My favorite quote on the subject is from Guido, http://mail.python.org/pipermail/python-3000/2008- March/012421.html : During the next 3 years or so, installing Py3k as the default python will be a deed of utter irresponsibility and is likely to break your system in subtle ways (both OSX and Linux these days use Python for certain system tasks). If you *really* want to shoot yourself in the foot this way, go ahead and explicitly use make altinstall bininstall or link it yourself. I propose that for Fedora we have /usr/bin/python3 for the system/default version of python 3 and /usr/bin/python for the system/default version of python 2. Both would be symlinks to a binary with the minor-release embedded in the name (/usr/bin/python3.1 and /usr/bin/python/2.6). As I understand things, this should make us broadly in agreement with upstream; see e.g.: http://mail.python.org/pipermail/python-dev/2009- April/088862.html http://mail.python.org/pipermail/python-dev/2009- April/04.html Could we do something similar to what qt and kdelibs packages have done? While qt3 was default, the 'qt' package points to qt3 and qt4 is an entirely separate package. When qt4 became default, qt3 was the one with the explicit version on it (and qt4 still exists, but the default 'qt' is qt4 now). This would mean that python2 packages grow 'Provides: python2-foo = %{version}-%{release}'. When python3 is the default, then have python point to python3 (and we can drop the Provides/Obsoletes for python3- prefixed packages later if wanted). My thought process is that I would not like, after python3 is the default, to still have to put the explicit 3 on there because python is still python2. Just thinking ahead here. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQIcBAEBCAAGBQJKxTdfAAoJEKaxavVX4C1Xdf0QANdjkM1iZhZfnxSLErl8qsrr Eqhg51xTZdolE/8/Z08DTxE3EF5yj5BsfGPgTfiyTgzqiFgMYpAxU6NYKRZI0WmL C3eC8oHMINRJGotklzHZiTnyUbZd2MZQuPWhMljOchOGOTktT9oaXZND/co1Aixo xNVqXLYQAYWAlF0A0fjVJ12x2eq4jcG8d2rDaOmiXMj4UTI1ZfVFyofBHm++4hUB dQ6JNrN11Tzd7fOnGZKvLUgvfEOXlP8K51dFKiaZI+iBxvU14GnU4e7p3ri4CEjT CKk8AzSKkwLcKk8ipCwN3+BvLCMvq91RtBoh1amhevCg2FgULnbe2ZWv9qhZkpJg EG4HVCbhXgeMvIbX6prGMtcDAe4X8QNesMX2C7OCqwwkFDea9qSNCb7ZLVscGCZQ OeRKfgD7DN1XnH/6F2a6p5lxNQF6EQ0G7oWjloSwWtOCNLTU+pDI1waTPM74yh/Y 1sabs31wYUi+gbW3sFqfWoMnkAisKRLXeKzxsZvotz4R87+GEwoV1ZZJNL+NWvZz V+IGhU+B6PTu8Jo6KfV2xJ6Y0kx8qKSlk9LdiZ9RKTyxgnZVaxj3YJceeUv1TSI/ U8xVwEjcMxDdink2NBlyGkd+its4+9ZlShHLMOKdYIAnibov72WlMLKXYNr8plpO kQYYB0B/z9A1fXFxNqKu =dgBR -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Thu, 2009-10-01 at 19:12 -0400, Ben Boeckel wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 David Malcolm wrote: 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) (we could extend this to have specific minor-releases (e.g. use python24- for a python 2.4 stack, in case some brave soul wants to get zope/plone running. But may be better to try to fix the zope/2.6 incompatibility at that point (caveat: haven't looked at the details of the issue). I don't intend to work on such versions)) 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? There have been various discussions upstream about what to call the python 3 binary. My favorite quote on the subject is from Guido, http://mail.python.org/pipermail/python-3000/2008- March/012421.html : During the next 3 years or so, installing Py3k as the default python will be a deed of utter irresponsibility and is likely to break your system in subtle ways (both OSX and Linux these days use Python for certain system tasks). If you *really* want to shoot yourself in the foot this way, go ahead and explicitly use make altinstall bininstall or link it yourself. I propose that for Fedora we have /usr/bin/python3 for the system/default version of python 3 and /usr/bin/python for the system/default version of python 2. Both would be symlinks to a binary with the minor-release embedded in the name (/usr/bin/python3.1 and /usr/bin/python/2.6). As I understand things, this should make us broadly in agreement with upstream; see e.g.: http://mail.python.org/pipermail/python-dev/2009- April/088862.html http://mail.python.org/pipermail/python-dev/2009- April/04.html Could we do something similar to what qt and kdelibs packages have done? While qt3 was default, the 'qt' package points to qt3 and qt4 is an entirely separate package. When qt4 became default, qt3 was the one with the explicit version on it (and qt4 still exists, but the default 'qt' is qt4 now). This would mean that python2 packages grow 'Provides: python2-foo = %{version}-%{release}'. When python3 is the default, then have python point to python3 (and we can drop the Provides/Obsoletes for python3- prefixed packages later if wanted). My thought process is that I would not like, after python3 is the default, to still have to put the explicit 3 on there because python is still python2. Just thinking ahead here. Thanks! If I'm correctly reading your mail, this approach is one I did think of, but I'm not fond of it. I think that anyone dealing with Python is going to have to be thinking is this python 2 or python 3 for some years to come, so having an explicit python3- prefix is probably not too painful. What I think would be painful in your suggestion is the flag day where we'd change the meaning of python- in RPM names. Currently in Fedora and EPEL, python- implies the system-supplied minor release of python 2, be it in Fedora (2.6), or in EPEL (2.4). I worry that changing it to imply the system-supplied minor release of Python 3 (3.1, or 3.2/3.3? by that point) would be thoroughly confusing, since we'd have to update everything all at once. It wouldn't fly within EPEL, since the pre-existing Enterprise downstreams of Fedora aren't going to change (far too disruptive). One middle ground might be to start using python2- explicitly for _new_ packages. That wouldn't break anything, but could easily be confusing as well. I think I prefer keeping things consistent. Perhaps at some point we could cut over /usr/bin/python from being Python 2 to Python 3, but I refer you again to this quote from Guido: http://mail.python.org/pipermail/python-3000/2008-March/012421.html (The other fun thing to do might be to package Unladen Swallow. Not at all sure what to call _that_ though!) Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 David Malcolm wrote: On Thu, 2009-10-01 at 19:12 -0400, Ben Boeckel wrote: Could we do something similar to what qt and kdelibs packages have done? While qt3 was default, the 'qt' package points to qt3 and qt4 is an entirely separate package. When qt4 became default, qt3 was the one with the explicit version on it (and qt4 still exists, but the default 'qt' is qt4 now). This would mean that python2 packages grow 'Provides: python2-foo = %{version}-%{release}'. When python3 is the default, then have python point to python3 (and we can drop the Provides/Obsoletes for python3- prefixed packages later if wanted). My thought process is that I would not like, after python3 is the default, to still have to put the explicit 3 on there because python is still python2. Just thinking ahead here. Thanks! If I'm correctly reading your mail, this approach is one I did think of, but I'm not fond of it. I think that anyone dealing with Python is going to have to be thinking is this python 2 or python 3 for some years to come, so having an explicit python3- prefix is probably not too painful. Package names wouldn't change for some time. Guido says 2--3 years, so python meaning python3 is some time away yet. What I think would be painful in your suggestion is the flag day where we'd change the meaning of python- in RPM names. Currently in Fedora and EPEL, python- implies the system-supplied minor release of python 2, be it in Fedora (2.6), or in EPEL (2.4). I worry that changing it to imply the system-supplied minor release of Python 3 (3.1, or 3.2/3.3? by that point) would be thoroughly confusing, since we'd have to update everything all at once. It wouldn't fly within EPEL, since the pre-existing Enterprise downstreams of Fedora aren't going to change (far too disruptive). This is where the 'Provides: python2-foo' kicks in. 'Requires:' in other packages would be updated to point to the python2-foo Provides for dependency solving. Over time, packages should be updated and if some deadline isn't met, start opening bugs, then finally using provenpackager when another deadline is hit. Even after the change, python3 packages would Provides/Obsoletes their old python3- names but would be moved to have the main package name be python-. Dependency chains should hold as long as the python2- and python3- Requires are used instead of the python- ones. One middle ground might be to start using python2- explicitly for _new_ packages. That wouldn't break anything, but could easily be confusing as well. I think I prefer keeping things consistent. This would still leave python2 to hold claim to the python- prefix and python3- left with the 3 in it. And I am for consistency here. Perhaps at some point we could cut over /usr/bin/python from being Python 2 to Python 3, but I refer you again to this quote from Guido: http://mail.python.org/pipermail/python-3000/2008- March/012421.html Yes, and after that time, what? Always use python3? I'd like to start a transition route worked out now before we start down towards python3 so that things aren't rushed later. (The other fun thing to do might be to package Unladen Swallow. Not at all sure what to call _that_ though!) Hopefully these changes will get merged some day. A faster python is on my list of wants for python (as well as a debugger and a valgrind-like tool to see where loose references are being kept). Dave - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQIcBAEBCAAGBQJKxUjTAAoJEKaxavVX4C1XuycQANByZEaH5Z0894ajjQKkEaaE IG35V4n1WBVVR/77UPh5sBtJtRvsYXIGduYDdZZL/cwAq8LXS8Kn0j8yOB8Y0V0z bU6WzAb6UAyZqxRYVL1DKsELAbzonqSTHr9g1as3bGiEsZchKjKNLM+C+RRGMpGr mgkWCZyyuCEUzt+fZSaQ11TMat2eWApLyDuNupmSkCIxzG7EI5R8ovYT2jiQ732W YUfnclY9sU3T/KhRUHsHCDsGsJOJMzt3SfZxrCgKzfdh3C/RuIi7v3u//1szGLk4 eK0XTruPwNrmkd7/kOwkjyFDVI/HnGWwvGnljz2bMfPC9he3qJdmPC03X1a91hTR M6Bljqd4m52X/IebPx+O4i9oEXByaK+UwYkvliEqUqPXdjYijGogTha0KQP8F1RU b0LFuPy1/MZ99Vizl++gwIKu5cXRuOu00H+G7sRbb0SnhY8qZUcz8HvgAR141lwY d34f8jnxCXlu0KorxHhg6qMstD6EoATA0wfPeGwPv8MWB6YD3ar5q8vkLykb6qQ/ VJONpAwNLMGGv03IzC60HG+s0kDlcJkdRjPzs20lj1siKS8N4Oza0FvBFFCcyCA5 G1w3BEzAILv2SbxCs9KRrvdUSjVmjC2HKnmYcT2wlv8Hv8Ec5BsN19i/UaYIAD/1 P5VAEUJafmJPovLw2oR6 =GaN9 -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Thu, Oct 1, 2009 at 3:17 PM, Toshio Kuratomi a.bad...@gmail.com wrote: I don't see any way around this atm but it is something to think about possibilities more. One way around this that I use at $DAYJOB (to minimize exposure of a PHP enabled webserver, thus minimizing attack surface, and also allowing apache to fail for a site without taking 15 unrelated sites with it), is to actually have two separate instances of httpd running, one with mod_python, and the other with mod_python3. Of course this requires manual intervention on the part of the local admin, but I would think that any admin that wanted to do this would be sufficiently competent to handle the intricacies of that choice. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list