[gentoo-dev] Re: [gentoo-python] New eclass for Python
On Tue, Feb 28, 2012 at 22:13, Krzysztof Pawlik nelch...@gentoo.org wrote: If there are no objections then during the weekend (March 3, 4) I will add this to portage (after finishing remaining TODO items, PyPy requires 4G of RAM(!!)). Can we perhaps just name it python-r2 rather than python-distutils-ng? Seems descriptive enough... Cheers, Dirkjan
Re: [gentoo-dev] New eclass for Python
On 28-02-2012 22:13:36 +0100, Krzysztof Pawlik wrote:
[good stuff]
Much appreciated!
From 2nd example ebuild:
python_install_all() {
rm -f ${D}/usr/bin/*.py || die
s/D/ED/ here for Prefix :)
I haven't checked the eclass in detail, but did you intend to make it
Prefix aware at all? I guess someone from us should test your work.
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: Digital signature
Re: [gentoo-dev] preserve_old_lib and I'm even more lazy
On 2/27/12 10:37 PM, Brian Dolbec wrote: I think somebody pointed some revdep-rebuild versions where exiting with successful code even when failed, was fixed version stabilized? No, it is only in - so far. It has not been released in a -0.3* ebuild yet. The last patch to revdep-rebuild fixing return codes is: http://git.overlays.gentoo.org/gitweb/?p=proj/gentoolkit.git;a=commit;h=3e51df74595c535656ef9f38bf7a577a4f64d0f5 from 11 days ago. If the maintainers of the package in question do not consider it important enough to do a release (not even mentioning stabilization), I don't think this is blocking. Any further objections? (I'm going to listen) signature.asc Description: OpenPGP digital signature
[gentoo-dev] The end of net-zope
Tomorrow, March 1, is the deadline for removing almost all of the Zope/Plone packages from the portage tree (those who still want them can get them from Arfrever's Progress overlay). Since only one or two packages would remain in the category, do we want the category to stay around, or should it be removed from the tree? We could move the remaining packages to dev-python. Similarly, there is an empty herd. Do we have a procedure for end-of-lifeing herds? Cheers, Dirkjan
Re: [gentoo-dev] Lastrite: gnunet, gnunet-gtk
On Wed, Feb 29, 2012 at 09:56:19AM +0200, Samuli Suominen wrote: # Samuli Suominen ssuomi...@gentoo.org (29 Feb 2012) # The old version of gnunet in portage is broken with the # new libextractor API. # Bugs 338909, #403461, #367677 and #260113. # Removal in 30 days unless fixed. net-p2p/gnunet net-p2p/gnunet-gtk Would be nice to just update the package to latest version (first mentioned bug) and solve all bugs at once. Also, it seems that 260113 has a fix (comment #2), but could be improved to a better fix. Piotr Szymaniak. -- - Oo, jesteś bystrzejszy, niż się wydaje. Przechodziłeś jakieś szkolenie antyterrorystyczne? - W pewnym sensie tak. Byłem żonaty. -- Nelson DeMille, The Lion's Game signature.asc Description: Digital signature
Re: [gentoo-dev] Gentoo Janitor scripts
On Mon, Feb 27, 2012 at 4:10 PM, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: On 2/20/12 6:03 PM, Corentin Chary wrote: Since I plan to use the remote remote-id tag for euscan, and I already use SRC_URI but I'd like all ebuild to use mirrors, I've wrote to scripts to cleanup your ebuilds and metadata. There are available here: https://github.com/iksaif/portage-janitor Here is what you can do with them: python remoteids.py --diff pycuda Test-Tester Alien-SDL ostinato --- a/dev-python/pycuda/metadata.xml +++ b/dev-python/pycuda/metadata.xml @@ -4,4 +4,7 @@ maintainer emailsp...@gentoo.org/email /maintainer + upstream + remote-id type=pypipycuda/remote-id + /upstream /pkgmetadata Maybe some bits could be integrated to repoman... I second that, those remoteids.py changes LGTM (look good to me). As always, I second any effort to make those useful things part of official Gentoo. Fix remote ids bug: https://bugs.gentoo.org/show_bug.cgi?id=406287 Fix mirrors bug: https://bugs.gentoo.org/show_bug.cgi?id=405533 -- Corentin Chary http://xf.iksaif.net
Re: [gentoo-dev] preserve_old_lib and I'm even more lazy
On Wed, 2012-02-29 at 09:45 +0100, Paweł Hajdan, Jr. wrote: On 2/27/12 10:37 PM, Brian Dolbec wrote: I think somebody pointed some revdep-rebuild versions where exiting with successful code even when failed, was fixed version stabilized? No, it is only in - so far. It has not been released in a -0.3* ebuild yet. The last patch to revdep-rebuild fixing return codes is: http://git.overlays.gentoo.org/gitweb/?p=proj/gentoolkit.git;a=commit;h=3e51df74595c535656ef9f38bf7a577a4f64d0f5 from 11 days ago. If the maintainers of the package in question do not consider it important enough to do a release (not even mentioning stabilization), I don't think this is blocking. Any further objections? (I'm going to listen) Yes, you are going to break systems if you do this change. If you really want to do this before we have a fixed gentoolkit to support it, then put yourself in the tools-portage herd and handle all of the bugs that arise out of the change. I just did a new release of gentoolkit-0.3.0.5 with the fixes in them so that you could do this change once it gets stable. Regards, Paul
Re: [gentoo-dev] New eclass for Python
On 29/02/12 09:17, Fabian Groffen wrote:
On 28-02-2012 22:13:36 +0100, Krzysztof Pawlik wrote:
[good stuff]
Much appreciated!
From 2nd example ebuild:
python_install_all() {
rm -f ${D}/usr/bin/*.py || die
s/D/ED/ here for Prefix :)
I haven't checked the eclass in detail, but did you intend to make it
Prefix aware at all? I guess someone from us should test your work.
Yes, please - take a look at my overlay (it always has the latest version) and
check for prefix related issues. Take a look also at xlwt and xlrd in dev-python
in the same overlay.
--
Krzysztof Pawlik nelchael at gentoo.org key id: 0xF6A80E46
desktop-misc, java, vim, kernel, python, apache...
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] New eclass for Python
On 29/02/12 04:21, Sergei Trofimovich wrote:
On Tue, 28 Feb 2012 22:13:36 +0100
Krzysztof Pawlik nelch...@gentoo.org wrote:
I'm attaching the eclass itself and two ebuilds using it, code is also
available
in my overlay at
http://git.overlays.gentoo.org/gitweb/?p=dev/nelchael.git;a=summary
Nice!
eclass/python-distutils-ng.eclass
236 # TODO: Pick default implementation
237 for impl in python{2_7,2_6,2_5,3_2,2_1} pypy{1_8,1_7}
jython2_5; do
Looks like 2_1 should be 3_1
Yes! Thank you.
minor suggestion:
s/_python-distutils-ng_run_for_all_impls/_python-distutils-ng_run_for_each_impl/g
LGTM, changed.
--
Krzysztof Pawlik nelchael at gentoo.org key id: 0xF6A80E46
desktop-misc, java, vim, kernel, python, apache...
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-python] New eclass for Python
On 29/02/12 06:13, Mike Gilbert wrote:
On Tue, Feb 28, 2012 at 4:13 PM, Krzysztof Pawlik nelch...@gentoo.org wrote:
Hello,
After some work during weekend on Python packages I've decided to start a
rewrite of Python/distutils eclass for installing Python packages. My main
goal
was simplicity and functionality similar to ruby-ng.eclass (thanks Ruby team
for
your great work!). Python team members already contributed comments and
suggestions and helped me to make the eclass better, thank you!
Highlights:
- *SIMPLE*next
- uses PYTHON_TARGETS use-expand (no more python-updater, wh!)
- EAPI4 required, uses REQUIRED_USE
- 400 lines of code including documentation
- should work for 95% of packages (my educated guess)
- did I mention it's *SIMPLE*?
- easy to maintain read so it's also easy to use
Important thing: I'm not aiming at having 100% functionality of current
python.eclass+distutils.eclass in the new one, I think that simplicity is
more
important that supporting every possible, obscure case that's out there.
I'm attaching the eclass itself and two ebuilds using it, code is also
available
in my overlay at
http://git.overlays.gentoo.org/gitweb/?p=dev/nelchael.git;a=summary
If there are no objections then during the weekend (March 3, 4) I will add
this
to portage (after finishing remaining TODO items, PyPy requires 4G of
RAM(!!)).
--
Krzysztof Pawlik nelchael at gentoo.org key id: 0xF6A80E46
desktop-misc, java, vim, kernel, python, apache...
# Phase function: src_unpack
python-distutils-ng_src_unpack() {
[[ ${PYTHON_OPTIONAL} = yes ]] { use python || return; }
if type python_unpack /dev/null; then
# This should not run anything specific to any single Python
# implementation, keep it generic:
python_unpack_all
else
[[ -n ${A} ]] unpack ${A}
fi
}
I think you meant to write if type python_unpack_all.
More to the point, I don't actually understand why this function
exists. It doesn't actually do anything that default_src_unpack does
not do already. Exporting it will clobber any vcs eclasses if the
inherit order is wrong.
You're right, I've killed the python-distutils-ng_src_unpack() function.
--
Krzysztof Pawlik nelchael at gentoo.org key id: 0xF6A80E46
desktop-misc, java, vim, kernel, python, apache...
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] New eclass for Python
On 29/02/12 08:49, Paweł Hajdan, Jr. wrote: On 2/28/12 10:13 PM, Krzysztof Pawlik wrote: Highlights: - 400 lines of code including documentation - should work for 95% of packages (my educated guess) - did I mention it's *SIMPLE*? - easy to maintain read so it's also easy to use This is awesome! Compare that to over 3000 LOC of python.eclass. :) Count distutils.eclass too: $ wc -l python-distutils-ng.eclass python.eclass distutils.eclass 364 python-distutils-ng.eclass 3168 python.eclass 592 distutils.eclass Important thing: I'm not aiming at having 100% functionality of current python.eclass+distutils.eclass in the new one, I think that simplicity is more important that supporting every possible, obscure case that's out there. Exactly. If there are no objections then during the weekend (March 3, 4) I will add this to portage (after finishing remaining TODO items, PyPy requires 4G of RAM(!!)). I second this so much (didn't review the eclass in detail, but it's obviously better than python.eclass). Thank you :) What's the plan to retire python.eclass? I'm not entirely sure - there's no pressure to migrate off it, both can coexist happily. I don't think it can be retired until be have all functionality from python.eclass+distutils.eclass somewhere (especially tests!). If the package is distutils-based then migration should be pretty painless and new packages (or version/revision bumps) can start using it as soon as it hits portage. -- Krzysztof Pawlik nelchael at gentoo.org key id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-python] New eclass for Python
On 29/02/12 09:11, Dirkjan Ochtman wrote: On Tue, Feb 28, 2012 at 22:13, Krzysztof Pawlik nelch...@gentoo.org wrote: If there are no objections then during the weekend (March 3, 4) I will add this to portage (after finishing remaining TODO items, PyPy requires 4G of RAM(!!)). Can we perhaps just name it python-r2 rather than python-distutils-ng? Seems descriptive enough... Yes and no - it's named python-distutils because main focus was this combination, it can work for other cases too, it's just that it combines functionality from both old eclasses. Besides I like the name, but I can be convinced to name it python-r2.eclass. -- Krzysztof Pawlik nelchael at gentoo.org key id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New eclass for Python
On Wed, 29 Feb 2012 18:38:22 +0100 Krzysztof Pawlik nelch...@gentoo.org wrote: On 29/02/12 08:49, Paweł Hajdan, Jr. wrote: This is awesome! Compare that to over 3000 LOC of python.eclass. :) Count distutils.eclass too: $ wc -l python-distutils-ng.eclass python.eclass distutils.eclass 364 python-distutils-ng.eclass 3168 python.eclass 592 distutils.eclass cvs/gentoo-x86/eclass $ cloc --by-file \ --force-lang=Bourne Again Shell,eclass python.eclass \ distutils .eclass python-distutils-ng.eclass 3 text files. 3 unique files. 0 files ignored. http://cloc.sourceforge.net v 1.55 T=0.5 s (6.0 files/s, 8294.0 lines/s) --- File blank comment code --- python.eclass396 288 2494 distutils.eclass 111 86 395 python-distutils-ng.eclass51 110 216 --- SUM: 558 484 3105 --- jer
Re: [gentoo-dev] Re: [gentoo-python] New eclass for Python
On Wed, Feb 29, 2012 at 12:39 PM, Krzysztof Pawlik nelch...@gentoo.org wrote: On 29/02/12 09:11, Dirkjan Ochtman wrote: On Tue, Feb 28, 2012 at 22:13, Krzysztof Pawlik nelch...@gentoo.org wrote: If there are no objections then during the weekend (March 3, 4) I will add this to portage (after finishing remaining TODO items, PyPy requires 4G of RAM(!!)). Can we perhaps just name it python-r2 rather than python-distutils-ng? Seems descriptive enough... Yes and no - it's named python-distutils because main focus was this combination, it can work for other cases too, it's just that it combines functionality from both old eclasses. Besides I like the name, but I can be convinced to name it python-r2.eclass. The distutils-based packages are a good starting point. The name is a good fit for that. Looking forward, I think it might make sense to move some of the functionality to a core python eclass that would just be for utility functions -- similar to the python/distutils split we have now. This would be used in ebuilds that are not primarily based around distutils (setup.py).
Re: [gentoo-dev] The end of net-zope
El mié, 29-02-2012 a las 09:51 +0100, Dirkjan Ochtman escribió: Tomorrow, March 1, is the deadline for removing almost all of the Zope/Plone packages from the portage tree (those who still want them can get them from Arfrever's Progress overlay). Since only one or two packages would remain in the category, do we want the category to stay around, or should it be removed from the tree? We could move the remaining packages to dev-python. Similarly, there is an empty herd. Do we have a procedure for end-of-lifeing herds? Cheers, Dirkjan You can see here how we dropped a herd last time from retirement: https://bugs.gentoo.org/show_bug.cgi?id=401169 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New eclass for Python
On Tue, 2012-02-28 at 22:13 +0100, Krzysztof Pawlik wrote: Hello, After some work during weekend on Python packages I've decided to start a rewrite of Python/distutils eclass for installing Python packages. My main goal was simplicity and functionality similar to ruby-ng.eclass (thanks Ruby team for your great work!). Python team members already contributed comments and suggestions and helped me to make the eclass better, thank you! Highlights: - *SIMPLE*next - uses PYTHON_TARGETS use-expand (no more python-updater, wh!) - EAPI4 required, uses REQUIRED_USE - 400 lines of code including documentation - should work for 95% of packages (my educated guess) - did I mention it's *SIMPLE*? - easy to maintain read so it's also easy to use Important thing: I'm not aiming at having 100% functionality of current python.eclass+distutils.eclass in the new one, I think that simplicity is more important that supporting every possible, obscure case that's out there. I'm attaching the eclass itself and two ebuilds using it, code is also available in my overlay at http://git.overlays.gentoo.org/gitweb/?p=dev/nelchael.git;a=summary If there are no objections then during the weekend (March 3, 4) I will add this to portage (after finishing remaining TODO items, PyPy requires 4G of RAM(!!)). The proposed eclass omits three features from python.eclass which are heavily used in the gnome stack. First, it does not set EPYTHON, which is a problem for the many packages whose build systems execute /usr/bin/python and assume that it's a generic python2 or the same version of python2.x for which the package is being built. 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? Third, python-distutils-ng_doscript() installs only one file at a time (no built-in support for multiple files at a time or for recursing through a directory tree), installs it only in /usr/bin (a package might want it in e.g. /usr/libexec or /usr/share/appname/scripts), and always creates scriptname-IMPLEMENTATION (polluting tab-completion in /usr/bin for the common case of programs that do not support multiple python ABIs). As a result, it is far less useful than python.eclass's python_convert_shebangs(). -Alexandre.
Re: [gentoo-dev] New eclass for Python
On 29/02/12 20:51, Alexandre Rostovtsev wrote:
On Tue, 2012-02-28 at 22:13 +0100, Krzysztof Pawlik wrote:
Hello,
After some work during weekend on Python packages I've decided to start a
rewrite of Python/distutils eclass for installing Python packages. My main
goal
was simplicity and functionality similar to ruby-ng.eclass (thanks Ruby team
for
your great work!). Python team members already contributed comments and
suggestions and helped me to make the eclass better, thank you!
Highlights:
- *SIMPLE*next
- uses PYTHON_TARGETS use-expand (no more python-updater, wh!)
- EAPI4 required, uses REQUIRED_USE
- 400 lines of code including documentation
- should work for 95% of packages (my educated guess)
- did I mention it's *SIMPLE*?
- easy to maintain read so it's also easy to use
Important thing: I'm not aiming at having 100% functionality of current
python.eclass+distutils.eclass in the new one, I think that simplicity is
more
important that supporting every possible, obscure case that's out there.
I'm attaching the eclass itself and two ebuilds using it, code is also
available
in my overlay at
http://git.overlays.gentoo.org/gitweb/?p=dev/nelchael.git;a=summary
If there are no objections then during the weekend (March 3, 4) I will add
this
to portage (after finishing remaining TODO items, PyPy requires 4G of
RAM(!!)).
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?
Regardless of this eclass you can still use python.eclass, it not going anywhere
anytime soon (just like I wrote in one of previous e-mails).
First, it does not set EPYTHON, which is a problem for the many packages
whose build systems execute /usr/bin/python and assume that it's a
generic python2 or the same version of python2.x for which the package
is being built.
Setting EPYTHON is not a problem -- just another variable.
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
Third, python-distutils-ng_doscript() installs only one file at a time
(no built-in support for multiple files at a time or for recursing
through a directory tree),
Yes, that why bash has `for' loop ;)
installs it only in /usr/bin (a package might
want it in e.g. /usr/libexec or /usr/share/appname/scripts)
Yes, I might add --destdir (or something like that) later on.
and always
creates scriptname-IMPLEMENTATION (polluting tab-completion in /usr/bin
for the common case of programs that do not support multiple python
ABIs). As a result, it is far less useful than python.eclass's
python_convert_shebangs().
Yes, that pollutes this name space, but I'm not buying this argument. Do you
know how CVS and .svn pollute my tab-completion list? I even set FIGNORE so I
can live with it.
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?
--
Krzysztof Pawlik nelchael at gentoo.org key id: 0xF6A80E46
desktop-misc, java, vim, kernel, python, apache...
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] New eclass for Python
Am Mittwoch 29 Februar 2012, 21:24:49 schrieb Krzysztof Pawlik: 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 We will hit the same problem with KDE (actually we already hit it): it has various types of scripting support, and each installs a KDE library linked to whatever language interpreter. (Now, that library- is it a Python/Ruby library or a KDE library? Because it is at the proper place for KDE stuff :) It's not just about calling an external language but also about embedding the interpreter for in-app scripting... and KDE rather heavily relies on python. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] New eclass for Python
On 29/02/12 22:08, Andreas K. Huettel wrote: Am Mittwoch 29 Februar 2012, 21:24:49 schrieb Krzysztof Pawlik: 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 We will hit the same problem with KDE (actually we already hit it): it has various types of scripting support, and each installs a KDE library linked to whatever language interpreter. (Now, that library- is it a Python/Ruby library or a KDE library? Because it is at the proper place for KDE stuff :) It's not just about calling an external language but also about embedding the interpreter for in-app scripting... and KDE rather heavily relies on python. I agree with last sentence - it's about embedding Python/Ruby/Foo, *this eclass is about installing packages for Python*. Compiling against an implementation is something completely different -- for example try building against Jython. -- Krzysztof Pawlik nelchael at gentoo.org key id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New eclass for Python
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.
