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
