From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
by finch.gentoo.org with esmtp (Exim 4.60)
(envelope-from <gentoo-dev+bounces-49990-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1S2rXJ-00084V-K9
for garchives@archives.gentoo.org; Wed, 29 Feb 2012 21:58:13 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 46957E0BB0;
Wed, 29 Feb 2012 21:57:55 +0000 (UTC)
Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183])
by pigeon.gentoo.org (Postfix) with ESMTP id A306EE0B41
for <gentoo-dev@lists.gentoo.org>; Wed, 29 Feb 2012 21:57:23 +0000 (UTC)
Received: from [192.168.1.43] (unknown [96.231.195.26])
(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by smtp.gentoo.org (Postfix) with ESMTPS id E43EB1B4020
for <gentoo-dev@lists.gentoo.org>; Wed, 29 Feb 2012 21:57:22 +0000 (UTC)
Message-ID: <1330552641.15103.93.camel@rook>
Subject: Re: [gentoo-dev] New eclass for Python
From: Alexandre Rostovtsev <tetromino@gentoo.org>
To: Gentoo Dev <gentoo-dev@lists.gentoo.org>
Date: Wed, 29 Feb 2012 16:57:21 -0500
In-Reply-To: <4F4E8991.8040907@gentoo.org>
References: <4F4D4380.9070909@gentoo.org> <1330545088.15103.62.camel@rook>
<4F4E8991.8040907@gentoo.org>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.2.3
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
Mime-Version: 1.0
X-Archives-Salt: 8f3eb384-524d-4c37-baea-61ba7a13acb7
X-Archives-Hash: 96d60787ff371c2c920b596098bc9ab4
On Wed, 2012-02-29 at 21:24 +0100, Krzysztof Pawlik wrote:
> On 29/02/12 20:51, Alexandre Rostovtsev wrote:
> > The proposed eclass omits three features from python.eclass which are
> > heavily used in the gnome stack.
>
> Correct me if I'm wrong, but Gnome doesn't use standard distutils?
Gnome is mostly written in C and therefore uses standard autotools :)
> > Second, there doesn't seem to be any support for packages that do not
> > install in python's site-packages and do not allow multiple python ABIs.
> > If I have, for example, a package that installs python modules
> > in /usr/lib/appname or /usr/share/appname, how can I specify that
> > PYTHON_TARGETS="python2.6" or "python2.7" or "python3.2" is allowed, but
> > something like PYTHON_TARGETS="python2.7 python3.2" is not?
>
> You're correct, note that I've stressed that this eclass is mainly for
> distutils-based packages. I'm not using Gnome, so can you provide some package
> examples that I can look at?
>
> <personal opinion>
> If package decides to use given language then please, please play by the rules
> set by the rest of world (Ruby -> gems, Python -> distutils, Perl -> CPAN, PHP
> -> PEAR).
>
> I don't like installing Python code outside of site-packages, the only exception
> to that rule is portage (at least for now).
> </personal opinion>
Some non-python packages allow python-based plugins. Obviously these
plugins live in the package's plugin directory (not in python's
site-packages) and use the package's main build system (not distutils),
and multiple python ABIs cannot be supported because that would result
in colliding plugins. Typical examples are app-editors/gedit,
media-gfx/gimp, media-sound/rhythmbox, or media-video/totem.
Some packages install a C library that links to a specific version of
libpython or that defines a particular python version string at compile
time, making it impossible to use the package with multiple python ABIs.
Examples I know are dev-libs/libpeas and dev-python/nautilus-python.
And then there are packages which could support e.g. multiple python2
ABIs in theory, but doing so in practice would require a fair bit of
patching, taking substantial effort with no real benefit for end users.
An example that springs to mind here is gnome-extra/zeitgeist.
> I'd be happy to hear how to solve this - what prefix or suffix to use? One way
> would be quite trivial: if only one implementation is enabled do not create
> script-${impl}, go with single file, does that sound good?
That would be the ideal solution.
-Alexandre.