Re: [gentoo-dev] New eclass for Python

[Krzysztof Pawlik <nelchael@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3380 bytes --]

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...


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 554 bytes --]