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...
signature.asc
Description: OpenPGP digital signature
