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
