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  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:
This is the separate-srpm approach, it would live as a separate package
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
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
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
So I just read this piece of news on the distutils-sig list. Here's a
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
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.
----- 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>
Subject: Re: [Distutils] Packaging Distribute
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>
> > 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
----- End forwarded message -----
(Resurrecting the "Proposal: Python 3 in Fedora 13" thread; see:
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:
> > "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
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
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
Again, following the combination of the two rules above:
> 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?
Python 2.6.3 was just released . 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
PS I'm about to be unreachable electronically, until October 12th
(vacation). I plan to start running rawhide when I'm back.