[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] New eclass for Python
From:       Alexandre Rostovtsev <tetromino () gentoo ! org>
Date:       2012-02-29 21:57:21
Message-ID: 1330552641.15103.93.camel () rook
[Download RAW message or body]

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.


[prev in list] [next in list] [prev in thread] [next in thread]