python-devel October 2009

python-devel@lists.fedoraproject.org

6 participants
5 discussions

Re: [Fedora-packaging] Proposal: naming convention for Python 3 packages and subpackages
by David Malcolm 02 Nov '09

02 Nov '09

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

3 5

distribute vs setuptools
by Toshio Kuratomi 31 Oct '09

31 Oct '09

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 <arfrever.fta(a)gmail.com> ----- Date: Thu, 8 Oct 2009 23:07:13 +0200 From: Arfrever Frehtes Taifersar Arahesis <arfrever.fta(a)gmail.com> To: distutils-sig(a)python.org Subject: Re: [Distutils] Packaging Distribute X-BeenThere: distutils-sig(a)python.org 2009-10-04 23:52:25 Sridhar Ratnakumar napisał(a): > On Sun, 04 Oct 2009 13:41:06 -0700, Tarek Ziadé <ziade.tarek(a)gmail.com> > 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(a)python.org http://mail.python.org/mailman/listinfo/distutils-sig ----- End forwarded message -----

4 4

Proposal: naming convention for Python 3 packages and subpackages
by David Malcolm 30 Oct '09

30 Oct '09

(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_.2… 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

3 4

Python 2.6.3 for Fedora 13?
by David Malcolm 13 Oct '09

13 Oct '09

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/

1 2

python3 proposal on fedora-devel
by Toshio Kuratomi 02 Oct '09

02 Oct '09

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

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-devel October 2009