| 1 |
On 29/02/12 22:57, Alexandre Rostovtsev wrote: |
| 2 |
> On Wed, 2012-02-29 at 21:24 +0100, Krzysztof Pawlik wrote: |
| 3 |
>> On 29/02/12 20:51, Alexandre Rostovtsev wrote: |
| 4 |
>>> The proposed eclass omits three features from python.eclass which are |
| 5 |
>>> heavily used in the gnome stack. |
| 6 |
>> |
| 7 |
>> Correct me if I'm wrong, but Gnome doesn't use standard distutils? |
| 8 |
> |
| 9 |
> Gnome is mostly written in C and therefore uses standard autotools :) |
| 10 |
|
| 11 |
Ok, thank you for this information. |
| 12 |
|
| 13 |
>>> Second, there doesn't seem to be any support for packages that do not |
| 14 |
>>> install in python's site-packages and do not allow multiple python ABIs. |
| 15 |
>>> If I have, for example, a package that installs python modules |
| 16 |
>>> in /usr/lib/appname or /usr/share/appname, how can I specify that |
| 17 |
>>> PYTHON_TARGETS="python2.6" or "python2.7" or "python3.2" is allowed, but |
| 18 |
>>> something like PYTHON_TARGETS="python2.7 python3.2" is not? |
| 19 |
>> |
| 20 |
>> You're correct, note that I've stressed that this eclass is mainly for |
| 21 |
>> distutils-based packages. I'm not using Gnome, so can you provide some package |
| 22 |
>> examples that I can look at? |
| 23 |
>> |
| 24 |
>> <personal opinion> |
| 25 |
>> If package decides to use given language then please, please play by the rules |
| 26 |
>> set by the rest of world (Ruby -> gems, Python -> distutils, Perl -> CPAN, PHP |
| 27 |
>> -> PEAR). |
| 28 |
>> |
| 29 |
>> I don't like installing Python code outside of site-packages, the only exception |
| 30 |
>> to that rule is portage (at least for now). |
| 31 |
>> </personal opinion> |
| 32 |
> |
| 33 |
> Some non-python packages allow python-based plugins. Obviously these |
| 34 |
> plugins live in the package's plugin directory (not in python's |
| 35 |
> site-packages) and use the package's main build system (not distutils), |
| 36 |
> and multiple python ABIs cannot be supported because that would result |
| 37 |
> in colliding plugins. Typical examples are app-editors/gedit, |
| 38 |
> media-gfx/gimp, media-sound/rhythmbox, or media-video/totem. |
| 39 |
> |
| 40 |
> Some packages install a C library that links to a specific version of |
| 41 |
> libpython or that defines a particular python version string at compile |
| 42 |
> time, making it impossible to use the package with multiple python ABIs. |
| 43 |
> Examples I know are dev-libs/libpeas and dev-python/nautilus-python. |
| 44 |
> |
| 45 |
> And then there are packages which could support e.g. multiple python2 |
| 46 |
> ABIs in theory, but doing so in practice would require a fair bit of |
| 47 |
> patching, taking substantial effort with no real benefit for end users. |
| 48 |
> An example that springs to mind here is gnome-extra/zeitgeist. |
| 49 |
|
| 50 |
I see - so it's the same case as with KDE (like Andreas wrote) - it's actually |
| 51 |
not a "python package" but rather an embedded Python. That's very different case |
| 52 |
than I'm targeting with this eclass (at least for now). |
| 53 |
|
| 54 |
>> I'd be happy to hear how to solve this - what prefix or suffix to use? One way |
| 55 |
>> would be quite trivial: if only one implementation is enabled do not create |
| 56 |
>> script-${impl}, go with single file, does that sound good? |
| 57 |
> |
| 58 |
> That would be the ideal solution. |
| 59 |
|
| 60 |
Ok, I've implemented this solution, now if one implementation is enabled there |
| 61 |
will be only one script, no foo-IMPL mangling. I've added also ability to |
| 62 |
install the script in other directory than /usr/bin. Hope this solves this case. |
| 63 |
|
| 64 |
Thank you for your comments and suggestions :) |
| 65 |
|
| 66 |
-- |
| 67 |
Krzysztof Pawlik <nelchael at gentoo.org> key id: 0xF6A80E46 |
| 68 |
desktop-misc, java, vim, kernel, python, apache... |
Archives