From a.badger at gmail.com Thu Oct 1 18:21:39 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 01 Oct 2009 11:21:39 -0700 Subject: python3 proposal on fedora-devel Message-ID: <4AC4F333.9060606@gmail.com> In case ya'll are filtering out fedora-devel list, David Malcolm has made a proposal for getting python3 into F13. https://www.redhat.com/archives/fedora-devel-list/2009-October/msg00054.html -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From jafo at tummy.com Thu Oct 1 20:42:13 2009 From: jafo at tummy.com (Sean Reifschneider) Date: Thu, 01 Oct 2009 14:42:13 -0600 Subject: python3 proposal on fedora-devel In-Reply-To: <4AC4F333.9060606@gmail.com> References: <4AC4F333.9060606@gmail.com> Message-ID: <4AC51425.1040004@tummy.com> On 10/01/2009 12:21 PM, Toshio Kuratomi wrote: > In case ya'll are filtering out fedora-devel list, David Malcolm has > made a proposal for getting python3 into F13. > > https://www.redhat.com/archives/fedora-devel-list/2009-October/msg00054.html This plan looks fine, but I do have some comments: /usr/bin/python3 is what the community has agreed on calling python 3.x. Don't worry at all about trying to call it anything else. Porting yum and RPM is going to require porting any of their non-Python-provided libraries. Doesn't look like there are that many dependencies though, pygpgme. I think it's easy to start now with a fairly minimal Python 3 stack, and add items as they get ported upstream. Sean -- Sean Reifschneider, Member of Technical Staff tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From dmalcolm at redhat.com Fri Oct 2 21:17:03 2009 From: dmalcolm at redhat.com (David Malcolm) Date: Fri, 02 Oct 2009 17:17:03 -0400 Subject: Python 2.6.3 for Fedora 13? Message-ID: <1254518223.9551.190.camel@radiator.bos.redhat.com> Python 2.6.3 was just released [1]. I think we'll want this in F13 (seems far too late to me for F12). I tried rebuilding our "devel" branch with the 2.6.3 tarball, and it built with no changes to the existing patches. I haven't gone through the upstream changes in detail though. Caveat: this was on an F11 box, not in Koji. I'm running with 2.6.3 rpms on my F11 box, I'll see if anything unexpected happens. yum seems to still work. Attached is a patch to the devel branch FWIW. I've just requested "watchbugzilla" "watchcommits" and "commit" rights for python's devel and F12 branches. Is there a process I need to go through for this, e.g. to establish trustworthiness? Hope this is helpful Dave PS I'm about to be unreachable electronically, until October 12th (vacation). I plan to start running rawhide when I'm back. [1] http://www.python.org/download/releases/2.6.3/ -------------- next part -------------- A non-text attachment was scrubbed... Name: bump-python-devel-to-2.6.3.patch Type: text/x-patch Size: 1664 bytes Desc: not available URL: From dmalcolm at redhat.com Fri Oct 2 21:28:09 2009 From: dmalcolm at redhat.com (David Malcolm) Date: Fri, 02 Oct 2009 17:28:09 -0400 Subject: python3 proposal on fedora-devel In-Reply-To: <4AC4F333.9060606@gmail.com> References: <4AC4F333.9060606@gmail.com> Message-ID: <1254518889.9551.195.camel@radiator.bos.redhat.com> On Thu, 2009-10-01 at 11:21 -0700, Toshio Kuratomi wrote: > In case ya'll are filtering out fedora-devel list, David Malcolm has > made a proposal for getting python3 into F13. > > https://www.redhat.com/archives/fedora-devel-list/2009-October/msg00054.html I guess I should have sent a pointer to here when I posted that; thanks. (It's not particularly clear when to post things to fedora-devel-list and when to this one. Python 3 seems big and "featurey" (if that's a word), so I opted for fedora-devel-list for that) Dave From dmalcolm at redhat.com Fri Oct 2 21:46:36 2009 From: dmalcolm at redhat.com (David Malcolm) Date: Fri, 02 Oct 2009 17:46:36 -0400 Subject: Python 2.6.3 for Fedora 13? In-Reply-To: <1254518223.9551.190.camel@radiator.bos.redhat.com> References: <1254518223.9551.190.camel@radiator.bos.redhat.com> Message-ID: <1254519997.9551.202.camel@radiator.bos.redhat.com> On Fri, 2009-10-02 at 17:17 -0400, David Malcolm wrote: > Python 2.6.3 was just released [1]. I think we'll want this in F13 > (seems far too late to me for F12). > > I tried rebuilding our "devel" branch with the 2.6.3 tarball, and it > built with no changes to the existing patches. I haven't gone through > the upstream changes in detail though. Caveat: this was on an F11 box, > not in Koji. Scratch build here: http://koji.fedoraproject.org/koji/taskinfo?taskID=1725285 [snip] From a.badger at gmail.com Thu Oct 8 21:55:33 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 8 Oct 2009 14:55:33 -0700 Subject: distribute vs setuptools Message-ID: <20091008215533.GB1240@clingman.lan> So I just read this piece of news on the distutils-sig list. Here's a summary/background. setuptools has become increasingly popular as a method of making python modules easier to package (by upstream), managing plugins, and getting version requirements right. However, the setuptools author has been somewhat lackadaisical about maintaining the code, integrating bugfixes, etc. Since the setuptools author hasn't wanted to pass the torch on to someone else, the project has forked. Distribute-0.6 is the compatible fork with multiple maintainers who are interested in preserving setuptools compatibility in the 0.6 branch and making real (but API changing) improvements in the 0.7 branch. Due to the non-maintenance of setuptools, some other Linux distros have started shipping distribute-0.6 as their setuptools module. Their plan is to ship distribute-0.6 as setuptools and distribute-0.7 as distribute. By doing this, the consumers of setuptools don't have to change their package (all the import statements) to use distribute instead of setuptools. If they didn't do this, the packages would need to be patched to use distribute instead of setuptools. The benefit of this is that they get a maintained piece of code with an upstream that is responsive to bug reports, patches, and takes distribution problems into consideration (even if they can't always do something about them in the 0.6 codebase). The downsides are that the setuptools upstream is alive even if it isn't thriving and the setuptools maintainer could throw a monkey into the works by releasing API breaking changes when he does a new setuptools release. Since I'm the current setuptools maintainer and have had issues trying to get bugs fixed in upstream setuptools before, I'm inclined to do this as well but the drawbacks are nothing to ignore. So what do other people think of our doing this as well? If we don't do this, an alternative might be to plan on packaging distribute0.6 and distribute0.7 parallel installable. Then we can port packages to use distribute instead of setuptools when its available and submit those patches to upstream projects. -Toshio ----- Forwarded message from Arfrever Frehtes Taifersar Arahesis ----- Date: Thu, 8 Oct 2009 23:07:13 +0200 From: Arfrever Frehtes Taifersar Arahesis To: distutils-sig at python.org Subject: Re: [Distutils] Packaging Distribute X-BeenThere: distutils-sig at python.org 2009-10-04 23:52:25 Sridhar Ratnakumar napisa?(a): > On Sun, 04 Oct 2009 13:41:06 -0700, Tarek Ziad? > wrote: > > > The other way would be to use Distribute instead of Setuptools for > > what the packaging system is calling "setuptools". That's pretty > > much what is happening in Gentoo (arch) and UHU-Linux (dev), > > right now > > Interesting. Gentoo uses distribute but retains the name 'setuptools'? It's because Distribute 0.6.* installs setuptools.* modules. Distribute 0.7.* will be under name dev-python/distribute. > Ah. But what if PJE releases setuptools with the *same* version number > 0.6.3? What would the gentoo folks do in order to get the new setuptools > release in their packaging system? Or did they make a decision of totally > dropping setuptools from their repository? We could switch to back to Setuptools only if Setuptools became more maintained than Distribute. -- Arfrever Frehtes Taifersar Arahesis _______________________________________________ Distutils-SIG maillist - Distutils-SIG at python.org http://mail.python.org/mailman/listinfo/distutils-sig ----- End forwarded message ----- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From ndbecker2 at gmail.com Fri Oct 9 11:35:12 2009 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 9 Oct 2009 07:35:12 -0400 Subject: distribute vs setuptools In-Reply-To: <20091008215533.GB1240@clingman.lan> References: <20091008215533.GB1240@clingman.lan> Message-ID: <200910090735.13163.ndbecker2@gmail.com> On Thursday 08 October 2009, Toshio Kuratomi wrote: > So I just read this piece of news on the distutils-sig list. Here's a > summary/background. > > setuptools has become increasingly popular as a method of making python > modules easier to package (by upstream), managing plugins, and getting > version requirements right. However, the setuptools author has been > somewhat lackadaisical about maintaining the code, integrating bugfixes, > etc. Since the setuptools author hasn't wanted to pass the torch on to > someone else, the project has forked. Distribute-0.6 is the compatible > fork with multiple maintainers who are interested in preserving setuptools > compatibility in the 0.6 branch and making real (but API changing) > improvements in the 0.7 branch. > > Due to the non-maintenance of setuptools, some other Linux distros have > started shipping distribute-0.6 as their setuptools module. Their plan is > to ship distribute-0.6 as setuptools and distribute-0.7 as distribute. By > doing this, the consumers of setuptools don't have to change their package > (all the import statements) to use distribute instead of setuptools. If > they didn't do this, the packages would need to be patched to use > distribute instead of setuptools. > > The benefit of this is that they get a maintained piece of code with an > upstream that is responsive to bug reports, patches, and takes distribution > problems into consideration (even if they can't always do something about > them in the 0.6 codebase). The downsides are that the setuptools upstream > is alive even if it isn't thriving and the setuptools maintainer could > throw a monkey into the works by releasing API breaking changes when he > does a new setuptools release. > > Since I'm the current setuptools maintainer and have had issues trying to > get bugs fixed in upstream setuptools before, I'm inclined to do this as > well but the drawbacks are nothing to ignore. So what do other people > think of our doing this as well? If we don't do this, an alternative > might be to plan on packaging distribute0.6 and distribute0.7 parallel > installable. Then we can port packages to use distribute instead of > setuptools when its available and submit those patches to upstream > projects. > > -Toshio > > ----- Forwarded message from Arfrever Frehtes Taifersar Arahesis > ----- > > Date: Thu, 8 Oct 2009 23:07:13 +0200 > From: Arfrever Frehtes Taifersar Arahesis > To: distutils-sig at python.org > Subject: Re: [Distutils] Packaging Distribute > X-BeenThere: distutils-sig at python.org > > 2009-10-04 23:52:25 Sridhar Ratnakumar napisa?(a): > > On Sun, 04 Oct 2009 13:41:06 -0700, Tarek Ziad? > > > > wrote: > > > The other way would be to use Distribute instead of Setuptools for > > > what the packaging system is calling "setuptools". That's pretty > > > much what is happening in Gentoo (arch) and UHU-Linux (dev), > > > right now > > > > Interesting. Gentoo uses distribute but retains the name 'setuptools'? > > It's because Distribute 0.6.* installs setuptools.* modules. > Distribute 0.7.* will be under name dev-python/distribute. > > > Ah. But what if PJE releases setuptools with the *same* version number > > 0.6.3? What would the gentoo folks do in order to get the new setuptools > > release in their packaging system? Or did they make a decision of totally > > dropping setuptools from their repository? > > We could switch to back to Setuptools only if Setuptools became more > maintained than Distribute. > +1 on switch to distribute. One drawback of setuptools is no uninstall. From what I've heard, distribute is more likely to have this sooner. From gael.varoquaux at normalesup.org Sun Oct 11 17:17:37 2009 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Sun, 11 Oct 2009 19:17:37 +0200 Subject: distribute vs setuptools In-Reply-To: <20091008215533.GB1240@clingman.lan> References: <20091008215533.GB1240@clingman.lan> Message-ID: <20091011171737.GD870@phare.normalesup.org> On Thu, Oct 08, 2009 at 02:55:33PM -0700, Toshio Kuratomi wrote: > Since I'm the current setuptools maintainer and have had issues trying to > get bugs fixed in upstream setuptools before, I'm inclined to do this as > well but the drawbacks are nothing to ignore. So what do other people think > of our doing this as well? If we don't do this, an alternative might be to > plan on packaging distribute0.6 and distribute0.7 parallel installable. > Then we can port packages to use distribute instead of setuptools when its > available and submit those patches to upstream projects. My gut feeling is +1. I have had long running gripes with both some bit of the code in setuptools, and the impossibility to improve them. Ga?l From dmalcolm at redhat.com Tue Oct 13 21:54:40 2009 From: dmalcolm at redhat.com (David Malcolm) Date: Tue, 13 Oct 2009 17:54:40 -0400 Subject: Python 2.6.3 for Fedora 13? In-Reply-To: <1254519997.9551.202.camel@radiator.bos.redhat.com> References: <1254518223.9551.190.camel@radiator.bos.redhat.com> <1254519997.9551.202.camel@radiator.bos.redhat.com> Message-ID: <1255470880.19562.6.camel@radiator.bos.redhat.com> On Fri, 2009-10-02 at 17:46 -0400, David Malcolm wrote: > On Fri, 2009-10-02 at 17:17 -0400, David Malcolm wrote: > > Python 2.6.3 was just released [1]. I think we'll want this in F13 > > (seems far too late to me for F12). > > > > I tried rebuilding our "devel" branch with the 2.6.3 tarball, and it > > built with no changes to the existing patches. I haven't gone through > > the upstream changes in detail though. Caveat: this was on an F11 box, > > not in Koji. > > Scratch build here: > http://koji.fedoraproject.org/koji/taskinfo?taskID=1725285 > > [snip] ...and upstream are reporting various failures with 2.6.3, and are hoping to get a 2.6.4 out of the door soon. Doh! FWIW I'm hoping to add a Fedora buildbot to the upstream buildbot farm. See https://fedorahosted.org/fedora-infrastructure/ticket/1717 for the details. Dave From dmalcolm at redhat.com Fri Oct 16 22:10:51 2009 From: dmalcolm at redhat.com (David Malcolm) Date: Fri, 16 Oct 2009 18:10:51 -0400 Subject: distribute vs setuptools In-Reply-To: <20091008215533.GB1240@clingman.lan> References: <20091008215533.GB1240@clingman.lan> Message-ID: <1255731051.26290.84.camel@radiator.bos.redhat.com> On Thu, 2009-10-08 at 14:55 -0700, Toshio Kuratomi wrote: > So I just read this piece of news on the distutils-sig list. Here's a > summary/background. > > setuptools has become increasingly popular as a method of making python > modules easier to package (by upstream), managing plugins, and getting > version requirements right. However, the setuptools author has been > somewhat lackadaisical about maintaining the code, integrating bugfixes, > etc. Since the setuptools author hasn't wanted to pass the torch on to > someone else, the project has forked. Distribute-0.6 is the compatible fork > with multiple maintainers who are interested in preserving setuptools > compatibility in the 0.6 branch and making real (but API changing) > improvements in the 0.7 branch. > > Due to the non-maintenance of setuptools, some other Linux distros have > started shipping distribute-0.6 as their setuptools module. Their plan is to > ship distribute-0.6 as setuptools and distribute-0.7 as distribute. By > doing this, the consumers of setuptools don't have to change their package > (all the import statements) to use distribute instead of setuptools. If > they didn't do this, the packages would need to be patched to use distribute > instead of setuptools. > > The benefit of this is that they get a maintained piece of code with an > upstream that is responsive to bug reports, patches, and takes distribution > problems into consideration (even if they can't always do something about > them in the 0.6 codebase). The downsides are that the setuptools upstream > is alive even if it isn't thriving and the setuptools maintainer could throw > a monkey into the works by releasing API breaking changes when he does a new > setuptools release. > > Since I'm the current setuptools maintainer and have had issues trying to > get bugs fixed in upstream setuptools before, I'm inclined to do this as > well but the drawbacks are nothing to ignore. So what do other people think > of our doing this as well? If we don't do this, an alternative might be to > plan on packaging distribute0.6 and distribute0.7 parallel installable. > Then we can port packages to use distribute instead of setuptools when its > available and submit those patches to upstream projects. You've got more knowledge in this area, so I'd tend to defer to your judgement here. One area that excites me about Distribute is support for Python 3 e.g. the idea of being able to run 2to3 as part of the build process. Not sure how sane that last one is, but it may be that we need Distribute in order to build out a python 3 stack in Fedora. Haven't checked the details yet though. [snip] From dmalcolm at redhat.com Thu Oct 29 22:27:35 2009 From: dmalcolm at redhat.com (David Malcolm) Date: Thu, 29 Oct 2009 18:27:35 -0400 Subject: Proposal: naming convention for Python 3 packages and subpackages In-Reply-To: <4AC50044.6090804@gmail.com> References: <1254417309.9551.34.camel@radiator.bos.redhat.com> <4AC50044.6090804@gmail.com> Message-ID: <1256855255.3731.3394.camel@brick> (Resurrecting the "Proposal: Python 3 in Fedora 13" thread; see: https://www.redhat.com/archives/fedora-devel-list/2009-October/msg00054.html and https://fedoraproject.org/wiki/Features/Python3F13 ) On Thu, 2009-10-01 at 12:17 -0700, Toshio Kuratomi wrote: > On 10/01/2009 10:15 AM, David Malcolm wrote: [snip] > > "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: Current naming conventions for Python packages are in https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Addon_Packages_.28python_modules.29 I rather like the idea of standardizing on a "python3-" prefix for _all_ Python 3 module packages and subpackages, even if this leads to inconsistencies with their counterparts in the python 2 stack. It would make the "threeness" of the packages stand out more. (NB: I hope that we'll eventually be in a place where we can cut over embedders and users of python (e.g. gedit, gdb, mod_python etc) from 2 to 3; I'm _not_ suggesting we do anything to their names. Obviously such a move is a long way off) > This seems fine even though it's a bit redundant: python3-pygtk2 and > python3-pygpgme. We could combine: - the "always use a python3-" rule I invented just above (ahem) and - the "When in doubt, use the name of the module that you type to import it in a script" advice from the python module guidelines. This would make the above examples be "python3-gtk" and "python3-gpgme" > 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. Again, following the combination of the two rules above: "python3-gstreamer" > 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 ? >From my reading of "rpm -qi gnome-python2", the upstream name is "gnome-python", so perhaps "python3-gnome" is the thing to use here? Thoughts? Dave From dmalcolm at redhat.com Fri Oct 30 00:15:01 2009 From: dmalcolm at redhat.com (David Malcolm) Date: Thu, 29 Oct 2009 20:15:01 -0400 Subject: [Fedora-packaging] Proposal: naming convention for Python 3 packages and subpackages In-Reply-To: <4AEA1A6B.10601@redhat.com> References: <1254417309.9551.34.camel@radiator.bos.redhat.com> <4AC50044.6090804@gmail.com> <1256855255.3731.3394.camel@brick> <4AEA1A6B.10601@redhat.com> Message-ID: <1256861701.3731.3552.camel@brick> On Thu, 2009-10-29 at 18:42 -0400, John Dennis wrote: > On 10/29/2009 06:27 PM, David Malcolm wrote: > > > I rather like the idea of standardizing on a "python3-" prefix for _all_ > > Python 3 module packages and subpackages, even if this leads to > > inconsistencies with their counterparts in the python 2 stack. It would > > make the "threeness" of the packages stand out more. > > > > Thoughts? > > Initially this sounds good to me. Because python 2 and python 3 are > incompatible it's probably important we separate them at the packaging > level, this seems like a good approach as any (even with some warts on > the corner cases). > > However package maintainers might not like the idea of having to > maintain double the number of their packages for an interim period and I > could see them wanting to have just one package that installs into both > the python2 and python3 library locations. Also perhaps we don't want to > inflate the number of python packages by 2x. Having not followed this > discussion from it's outset I'm wondering if we might want to consider > allowing a single python package to support both python versions. I'm > sure there are multiple reasons why this is a horrible idea, but I > thought I would throw it out for consideration and let it get shot down :-) My original proposal [1] was that python 3 should be entirely separate from python 2 As a trial run, I took a packaged python module and got it to build with python 3. See: https://bugzilla.redhat.com/show_bug.cgi?id=531648 This is the separate-srpm approach, it would live as a separate package in CVS. As an experiment, I tried hacking up the same module's specfile so that one build generates both 2 and 3 subpackages. You can see the result here: https://bugzilla.redhat.com/show_bug.cgi?id=531895 This approach requires the package to work with both python 2 and 3, which requires both an upstream maintainer and a downstream Fedora packager that care about both 2 and 3, working from a single source tree. For supporting both 2 and 3 with a single built RPM (or something involving symlinked .py files?) I don't think that's possible: we don't want to add a python3 dependency to python 2 modules, and the precompiled bytecode optimization of imports requires version-specific .pyc/.pyo files - see bug 531117 (automating this in rpmbuild) and bug 531102 (adding a test to rpmlint to verify that it got it correct). Dave [1] See: https://www.redhat.com/archives/fedora-devel-list/2009-October/msg00054.html and https://fedoraproject.org/wiki/Features/Python3F13 From a.badger at gmail.com Fri Oct 30 01:50:17 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 29 Oct 2009 18:50:17 -0700 Subject: Proposal: naming convention for Python 3 packages and subpackages In-Reply-To: <1256855255.3731.3394.camel@brick> References: <1254417309.9551.34.camel@radiator.bos.redhat.com> <4AC50044.6090804@gmail.com> <1256855255.3731.3394.camel@brick> Message-ID: <20091030015017.GB19447@clingman.lan> On Thu, Oct 29, 2009 at 06:27:35PM -0400, David Malcolm wrote: > > Current naming conventions for Python packages are in > https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Addon_Packages_.28python_modules.29 > > I rather like the idea of standardizing on a "python3-" prefix for _all_ > Python 3 module packages and subpackages, even if this leads to > inconsistencies with their counterparts in the python 2 stack. It would > make the "threeness" of the packages stand out more. > > (NB: I hope that we'll eventually be in a place where we can cut over > embedders and users of python (e.g. gedit, gdb, mod_python etc) from 2 > to 3; I'm _not_ suggesting we do anything to their names. Obviously > such a move is a long way off) > +1 to this section mod_python is something we might have to consider differently than the other packages in your example set since it's going to be running end user created code. > > This seems fine even though it's a bit redundant: python3-pygtk2 and > > python3-pygpgme. > > We could combine: > - the "always use a python3-" rule I invented just above (ahem) and > - the "When in doubt, use the name of the module that you type to > import it in a script" advice from the python module guidelines. > > This would make the above examples be "python3-gtk" and "python3-gpgme" > I'm tentatively for this. My hesitation comes since I know maintainers already question the module name portion of the Guidelines. But they still have a choice... it's just going to appear a bit funnier: python3-pygtk2 or python3-gtk, their choice. There are also modules where there's ony one choice: python3-pycurl It's fine though. > > 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. > > Again, following the combination of the two rules above: > "python3-gstreamer" > +1 I wish that all the python2 bindings followed this scheme as well. > > 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 ? > >From my reading of "rpm -qi gnome-python2", the upstream name is > "gnome-python", so perhaps "python3-gnome" is the thing to use here? > > Thoughts? > Sounds good. Write it up and lets get it approved. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From jafo at tummy.com Fri Oct 30 02:54:01 2009 From: jafo at tummy.com (Sean Reifschneider) Date: Thu, 29 Oct 2009 20:54:01 -0600 Subject: Proposal: naming convention for Python 3 packages and subpackages In-Reply-To: <20091030015017.GB19447@clingman.lan> References: <1254417309.9551.34.camel@radiator.bos.redhat.com> <4AC50044.6090804@gmail.com> <1256855255.3731.3394.camel@brick> <20091030015017.GB19447@clingman.lan> Message-ID: <4AEA5549.70406@tummy.com> On 10/29/2009 07:50 PM, Toshio Kuratomi wrote: > +1 to this section In general I'm +1 to everything you said, Toshio, but just to clarify. > mod_python is something we might have to consider differently than the other In my mind the difference is between modules/libraries and python add-ons to other applications. So, it's very natural that python3-gnome starts with "python3" because you use it with the Python "application", as it's a library. And it's natural the mod_python or vim+python be "httpd-mod_python3" or "vim-python3" because they are components to the http and vim applications. The place it gets strange is for something like Idle, which is an application in it's own right, but is used with Python development. I almost want something like the "lib" prefix that is used to mark system libraries, but for python. Like "python3-libpsycopg2". Then I could search explicitly for modules with "yum search python-lib"... That's a pretty drastic change though, and would probably make more sense in combination with "perl-lib", etc... Probably not a good idea, but it feels somewhat natural. Sean -- Sean Reifschneider, Member of Technical Staff tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From tim.lauridsen at googlemail.com Fri Oct 30 08:57:02 2009 From: tim.lauridsen at googlemail.com (Tim Lauridsen) Date: Fri, 30 Oct 2009 09:57:02 +0100 Subject: [Fedora-packaging] Proposal: naming convention for Python 3 packages and subpackages In-Reply-To: <1256861701.3731.3552.camel@brick> References: <1254417309.9551.34.camel@radiator.bos.redhat.com> <4AC50044.6090804@gmail.com> <1256855255.3731.3394.camel@brick> <4AEA1A6B.10601@redhat.com> <1256861701.3731.3552.camel@brick> Message-ID: <4AEAAA5E.4040501@googlemail.com> On 10/30/2009 01:15 AM, David Malcolm wrote: > On Thu, 2009-10-29 at 18:42 -0400, John Dennis wrote: >> On 10/29/2009 06:27 PM, David Malcolm wrote: >> >>> I rather like the idea of standardizing on a "python3-" prefix for _all_ >>> Python 3 module packages and subpackages, even if this leads to >>> inconsistencies with their counterparts in the python 2 stack. It would >>> make the "threeness" of the packages stand out more. >>> >>> Thoughts? >> for the python- -> python3- py -> python3-py (I think we should keep the py to make it easier to locate stuff pygpgme) -python -> python3- Seem good to me. But there is a lot of packages installing stuff into /usr/lib/pythonX-Y/site-packages there don't fit 3 cases. Ex. yum It is an application, but also an python API used by other packages, how do we handle there cases. I have attacted the the sorted output from repoquery -f '/usr/lib/python2.6/site-packages/*' Tim -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: python-site-pgks-sort.txt URL: From tim.lauridsen at googlemail.com Fri Oct 30 09:28:29 2009 From: tim.lauridsen at googlemail.com (Tim Lauridsen) Date: Fri, 30 Oct 2009 10:28:29 +0100 Subject: [Fedora-packaging] Proposal: naming convention for Python 3 packages and subpackages In-Reply-To: <4AEAAA5E.4040501@googlemail.com> References: <1254417309.9551.34.camel@radiator.bos.redhat.com> <4AC50044.6090804@gmail.com> <1256855255.3731.3394.camel@brick> <4AEA1A6B.10601@redhat.com> <1256861701.3731.3552.camel@brick> <4AEAAA5E.4040501@googlemail.com> Message-ID: <4AEAB1BD.8050606@googlemail.com> On 10/30/2009 09:57 AM, Tim Lauridsen wrote: > On 10/30/2009 01:15 AM, David Malcolm wrote: >> On Thu, 2009-10-29 at 18:42 -0400, John Dennis wrote: >>> On 10/29/2009 06:27 PM, David Malcolm wrote: >>> >>>> I rather like the idea of standardizing on a "python3-" prefix for >>>> _all_ >>>> Python 3 module packages and subpackages, even if this leads to >>>> inconsistencies with their counterparts in the python 2 stack. It would >>>> make the "threeness" of the packages stand out more. >>>> >>>> Thoughts? >>> > > for the > > python- -> python3- > py -> python3-py (I think we should keep the py to > make it easier to locate stuff pygpgme) > -python -> python3- > > Seem good to me. > > But there is a lot of packages installing stuff into > /usr/lib/pythonX-Y/site-packages there don't fit 3 cases. > > Ex. yum > > It is an application, but also an python API used by other packages, how > do we handle there cases. > > I have attacted the the sorted output from > > repoquery -f '/usr/lib/python2.6/site-packages/*' > > Tim > I have added a ordered file categorizing the packages in Tim -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: python3-namining-types.txt URL: From dmalcolm at redhat.com Fri Oct 30 16:11:11 2009 From: dmalcolm at redhat.com (David Malcolm) Date: Fri, 30 Oct 2009 12:11:11 -0400 Subject: [Fedora-packaging] Proposal: naming convention for Python 3 packages and subpackages In-Reply-To: <4AEAB1BD.8050606@googlemail.com> References: <1254417309.9551.34.camel@radiator.bos.redhat.com> <4AC50044.6090804@gmail.com> <1256855255.3731.3394.camel@brick> <4AEA1A6B.10601@redhat.com> <1256861701.3731.3552.camel@brick> <4AEAAA5E.4040501@googlemail.com> <4AEAB1BD.8050606@googlemail.com> Message-ID: <1256919073.10194.102.camel@brick> On Fri, 2009-10-30 at 10:28 +0100, Tim Lauridsen wrote: > On 10/30/2009 09:57 AM, Tim Lauridsen wrote: > > On 10/30/2009 01:15 AM, David Malcolm wrote: > >> On Thu, 2009-10-29 at 18:42 -0400, John Dennis wrote: > >>> On 10/29/2009 06:27 PM, David Malcolm wrote: > >>> > >>>> I rather like the idea of standardizing on a "python3-" prefix for > >>>> _all_ > >>>> Python 3 module packages and subpackages, even if this leads to > >>>> inconsistencies with their counterparts in the python 2 stack. It would > >>>> make the "threeness" of the packages stand out more. > >>>> > >>>> Thoughts? > >>> > > > > for the > > > > python- -> python3- > > py -> python3-py (I think we should keep the py to > > make it easier to locate stuff pygpgme) > > -python -> python3- > > > > Seem good to me. > > > > But there is a lot of packages installing stuff into > > /usr/lib/pythonX-Y/site-packages there don't fit 3 cases. > > > > Ex. yum > > > > It is an application, but also an python API used by other packages, how > > do we handle there cases. > > > > I have attacted the the sorted output from > > > > repoquery -f '/usr/lib/python2.6/site-packages/*' > > > > Tim > > > > I have added a ordered file categorizing the packages in > Very nice, thanks! In my email I said "Python 3 module packages and subpackages", and I'm not being very precise about this. Can a distinction can be drawn between an rpm that "merely" packages a python module? I think that many of our rpms have payloads that are entirely below: /usr/lib/python2.6/site-packages /usr/share/doc/NAME-VERSION I suspect that most of the packages within these lists fall into this category: "Packages starting with 'python-':" "Packages starting with 'Py' or 'py' (but not 'python-')" "Packages ending with '-python':" (most of these seem to be subpackages from a mostly non-python build) Contrast this with the "None of the above:" category. At a quick look, most of the packages in this list appear to be using python as an implementation detail, in order to get some user-facing job done. For these, I feel we'd port them one-by-one, and the name need not change. A complication/exception in this last category is for plugin systems and "stacks". For example, yum and its various plugins/extensions don't mention python in their name, but they're written in python 2. Similarly, Django and the various django-foo packages implement the Django web development framework, which happens to be written in python 2 (hopefully will eventually have python 3 support), and "trac-foo". My gut feeling for both of these cases is that we'd want python 2 and 3 versions for a while, so perhaps a python3- prefix is ok. That would give us e.g.: python3-trac-privateticketsplugin python3-TurboGears python3-TurboGears2 python3-yum I noticed "wxPython" in the "none of the above" naming bucket. This one definitely feels like a support module, rather than a thing to be used in its own right (python bindings to the wxWidgets library). - wxPython3 ? - python3-wx ? etc not sure; maybe depends on upstream. Does the "purely a module" vs "is something uservisible" vs "is a stack" distinction sound sane? Dave From a.badger at gmail.com Sat Oct 31 00:35:36 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 30 Oct 2009 17:35:36 -0700 Subject: [Fedora-packaging] Proposal: naming convention for Python 3 packages and subpackages In-Reply-To: <1256919073.10194.102.camel@brick> References: <1254417309.9551.34.camel@radiator.bos.redhat.com> <4AC50044.6090804@gmail.com> <1256855255.3731.3394.camel@brick> <4AEA1A6B.10601@redhat.com> <1256861701.3731.3552.camel@brick> <4AEAAA5E.4040501@googlemail.com> <4AEAB1BD.8050606@googlemail.com> <1256919073.10194.102.camel@brick> Message-ID: <20091031003536.GC19447@clingman.lan> On Fri, Oct 30, 2009 at 12:11:11PM -0400, David Malcolm wrote: > Very nice, thanks! > > In my email I said "Python 3 module packages and subpackages", and I'm > not being very precise about this. > > Can a distinction can be drawn between an rpm that "merely" packages a > python module? I think that many of our rpms have payloads that are > entirely below: > /usr/lib/python2.6/site-packages > /usr/share/doc/NAME-VERSION > I suspect that most of the packages within these lists fall into this > category: > "Packages starting with 'python-':" > "Packages starting with 'Py' or 'py' (but not 'python-')" > "Packages ending with '-python':" (most of these seem to be > subpackages from a mostly non-python build) > > > Contrast this with the "None of the above:" category. At a quick look, > most of the packages in this list appear to be using python as an > implementation detail, in order to get some user-facing job done. For > these, I feel we'd port them one-by-one, and the name need not change. > > A complication/exception in this last category is for plugin systems and > "stacks". For example, yum and its various plugins/extensions don't > mention python in their name, but they're written in python 2. > Similarly, Django and the various django-foo packages implement the > Django web development framework, which happens to be written in python > 2 (hopefully will eventually have python 3 support), and "trac-foo". My > gut feeling for both of these cases is that we'd want python 2 and 3 > versions for a while, so perhaps a python3- prefix is ok. That would > give us e.g.: > python3-trac-privateticketsplugin > python3-TurboGears > python3-TurboGears2 > python3-yum > > I noticed "wxPython" in the "none of the above" naming bucket. This one > definitely feels like a support module, rather than a thing to be used > in its own right (python bindings to the wxWidgets library). > - wxPython3 ? > - python3-wx ? > etc not sure; maybe depends on upstream. > I'd apply your rules to allow either of the following: - python3-wxPython - python3-wx > Does the "purely a module" vs "is something uservisible" vs "is a stack" > distinction sound sane? > It sounds sane but isn't really :-( let's take a few cases, yum, gourmet, setuptools, and bzr. yum is used by most people as an application. It has both a private library in /usr/share/yum and a public library in %{python_sitelib}/yum. Numerically, most consumers of yum are plugins to yum (so they'd need to be written in the same python version as yum). However, there are users of the public library that are their ownstandalone tools. Those tools could be ported to python3 independently of yum itself. gourmet is a gtk application. It is largely implemented as a library in %{python_sitelib}/gourmet. setuptools is two python modules: setuptools and pkg_resources. It also has a script, easy_install. For many end users, easy_install is becoming the way that they use setuptools but for developers, pkg_resources is the primary use. (although developers are coming to use easy_install as well especially coupled with virtualenv). bzr is a command line version control system and a python library. bzr takes plugins. The library is used in other aps that want to integrate with bzr. (bzr-eclipse, bzr-explorer, etc). Everything except a small script for running the commandline are in %{python_sitelib}/bzrlib. Ways to deal with this: -Yum * yum could be split into a main yum package that includes /usr/bin/yum and the private library. Whether this is python2 or 3 doesn't matter yet. It would also have python-yum and python3-yum packages that has the public library available to both versions of yum. This makes sense to me because yum is well written and organized in this sense. -gourmet * gourmet has plugins. It's also installed into the public library location. I don't know of anything that uses the libraries, though (not even external plugins). We could continue to treat this as a pure application at this time and just install a gourmet package where python2/3 is an implementation detail that does not need to be shown. -setuptools * setuptools can be split to have a subpackage named simply "easy_install" with the easy_install script. This is a bit odd as the script is just a thin wrapper against code in the setuptools module (setuptools is not organized around public and private interfaces like yum is). In this scenario, you'd have python-setuptools, python3-setuptools, easy_install and easy_install-3 (if the maintainers of python-setuptools and python3-setuptools couldn't agree on having a single script). End users are used to getting easy_install from the setuptools package so I don't think this helps them much. * The packages are called python-setuptools and python3-setuptools and we ignore the fact that there's a script in the package. -bzr * UGH! I think we'll need to split these packages artificially and somewhat inefficiently: bzr package with the /usr/bin/bzr script. python3-bzrlib and python-bzrlib packages for the library. Note that if the upstream community ports to python3 all at the same time, we wouldn't have to worry about this. So probably we continue to have a monolithic bzr package until bzr/bzrlib is ported to python3. Then, if needed for other front end consumers of bzrlib, we make the split like this: python-bzrlib (python2), bzr (python3), python3-bzrlib (is this one necessary?) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From a.badger at gmail.com Sat Oct 31 00:38:23 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 30 Oct 2009 17:38:23 -0700 Subject: Proposal: naming convention for Python 3 packages and subpackages In-Reply-To: <4AEA5549.70406@tummy.com> References: <1254417309.9551.34.camel@radiator.bos.redhat.com> <4AC50044.6090804@gmail.com> <1256855255.3731.3394.camel@brick> <20091030015017.GB19447@clingman.lan> <4AEA5549.70406@tummy.com> Message-ID: <20091031003823.GD19447@clingman.lan> On Thu, Oct 29, 2009 at 08:54:01PM -0600, Sean Reifschneider wrote: > On 10/29/2009 07:50 PM, Toshio Kuratomi wrote: > > +1 to this section > > In general I'm +1 to everything you said, Toshio, but just to clarify. > > > mod_python is something we might have to consider differently than the other > > In my mind the difference is between modules/libraries and python add-ons > to other applications. > > So, it's very natural that python3-gnome starts with "python3" because you > use it with the Python "application", as it's a library. And it's natural > the mod_python or vim+python be "httpd-mod_python3" or "vim-python3" > because they are components to the http and vim applications. > > The place it gets strange is for something like Idle, which is an > application in it's own right, but is used with Python development. > > I almost want something like the "lib" prefix that is used to mark > system libraries, but for python. Like "python3-libpsycopg2". Then I > could search explicitly for modules with "yum search python-lib"... That's > a pretty drastic change though, and would probably make more sense in > combination with "perl-lib", etc... > > Probably not a good idea, but it feels somewhat natural. > I think we're generally using python- (inconsistently) and python3- (want to make this 100% consistent) asour lib prefixfor python libraries. Is Idle just a python application or is it also used as a library? I'm afraid I haven't looked so I don't know how strange it is under this scheme. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From jafo at tummy.com Sat Oct 31 00:52:05 2009 From: jafo at tummy.com (Sean Reifschneider) Date: Fri, 30 Oct 2009 18:52:05 -0600 Subject: Proposal: naming convention for Python 3 packages and subpackages In-Reply-To: <20091031003823.GD19447@clingman.lan> References: <1254417309.9551.34.camel@radiator.bos.redhat.com> <4AC50044.6090804@gmail.com> <1256855255.3731.3394.camel@brick> <20091030015017.GB19447@clingman.lan> <4AEA5549.70406@tummy.com> <20091031003823.GD19447@clingman.lan> Message-ID: <4AEB8A35.1010804@tummy.com> On 10/30/2009 06:38 PM, Toshio Kuratomi wrote: > I think we're generally using python- (inconsistently) and python3- (want to > make this 100% consistent) asour lib prefixfor python libraries. I guess that's true with the exception of the python base package itself which is both a library *AND* an application, and things like idle. > Is Idle > just a python application or is it also used as a library? I'm afraid I > haven't looked so I don't know how strange it is under this scheme. The thing about idle is that it's provided by Python, it's not a library, but it's only used by developers of Python with Python. So, it's not a library, but it doesn't feel to me like it should be just called "idle" as opposed to "python(3)?-idle". Sean -- Sean Reifschneider, Member of Technical Staff tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From a.badger at gmail.com Sat Oct 31 17:06:10 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 31 Oct 2009 10:06:10 -0700 Subject: distribute vs setuptools In-Reply-To: <1255731051.26290.84.camel@radiator.bos.redhat.com> References: <20091008215533.GB1240@clingman.lan> <1255731051.26290.84.camel@radiator.bos.redhat.com> Message-ID: <20091031170610.GA860@clingman.lan> On Fri, Oct 16, 2009 at 06:10:51PM -0400, David Malcolm wrote: > > One area that excites me about Distribute is support for Python 3 e.g. > the idea of being able to run 2to3 as part of the build process. Not > sure how sane that last one is, but it may be that we need Distribute in > order to build out a python 3 stack in Fedora. Haven't checked the > details yet though. > The current python-setuptools in rawhide (F-13) is now distribute. Let me know/file a bug/etc if something starts to fail unepexctedly. (abadger1999 on freenode is the best way to get quick help). Couple review bugs of sorts to work out details of packaging for python3: https://bugzilla.redhat.com/show_bug.cgi?id=531648 https://bugzilla.redhat.com/show_bug.cgi?id=531895 There's a lot of options. We need to figure out which of those is the most sane. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: