Gentoo Archives: gentoo-dev

From: Krzysztof Pawlik <nelchael@g.o>
To: gentoo-dev@l.g.o
Cc: Alexandre Rostovtsev <tetromino@g.o>
Subject: Re: [gentoo-dev] New eclass for Python
Date: Thu, 01 Mar 2012 18:43:03
Message-Id: 4F4FC2FA.7000403@gentoo.org
In Reply to: Re: [gentoo-dev] New eclass for Python by Alexandre Rostovtsev
On 29/02/12 22:57, Alexandre Rostovtsev wrote:
> 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 :)
Ok, thank you for this information.
>>> 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 see - so it's the same case as with KDE (like Andreas wrote) - it's actually not a "python package" but rather an embedded Python. That's very different case than I'm targeting with this eclass (at least for now).
>> 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.
Ok, I've implemented this solution, now if one implementation is enabled there will be only one script, no foo-IMPL mangling. I've added also ability to install the script in other directory than /usr/bin. Hope this solves this case. Thank you for your comments and suggestions :) -- Krzysztof Pawlik <nelchael at gentoo.org> key id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache...

Attachments

File name MIME type
signature.asc application/pgp-signature