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