1 |
On Sun, 9 Sep 2012 11:21:56 -0400 |
2 |
Mike Gilbert <floppym@g.o> wrote: |
3 |
|
4 |
> On Sun, Sep 9, 2012 at 4:33 AM, Michał Górny <mgorny@g.o> |
5 |
> wrote: |
6 |
> > Hello, |
7 |
> > |
8 |
> > After some thinking, I think I found an optimal solution to |
9 |
> > implementing various kinds of Python dependencies and |
10 |
> > PYTHON_USE_WITH*. |
11 |
> > |
12 |
> > As a note, all variable names are dirty and not official. Feel free |
13 |
> > to suggest better ones. |
14 |
> > |
15 |
> > 1. Add a user-defined variable PYTHON_USE. If user needed any |
16 |
> > specific flags from a Python dependency, he can set the USE |
17 |
> > dependency string there. The string will have to follow the general |
18 |
> > rules for USE dependencies and be correct for every Python |
19 |
> > implementation specified in PYTHON_COMPAT (this may require USE |
20 |
> > defaults). For example: |
21 |
> > |
22 |
> > PYTHON_USE="ncurses,sqlite" |
23 |
> > |
24 |
> > 2. Add a eclass-defined variable PYTHON_DEPEND. It will be always |
25 |
> > exported, and contain a dependency string created using |
26 |
> > PYTHON_COMPAT and PYTHON_USE -- the most simple and most common |
27 |
> > one, e.g.: |
28 |
> > |
29 |
> > PYTHON_DEPEND=" |
30 |
> > python_targets_pythonX_Y? |
31 |
> > ( dev-python/python:X.Y[ncurses,sqlite] ) |
32 |
> > " |
33 |
> > |
34 |
> > 3. By default, just append PYTHON_DEPEND to DEPEND and RDEPEND. |
35 |
> > Provide an option to disable that. If user wants optional Python, |
36 |
> > he can disable it and use ${PYTHON_DEPEND} in his own *DEPEND code. |
37 |
> > (we could also provide a quick switch to add 'python? ( )' or |
38 |
> > '$USEFLAG? ( )'). |
39 |
> > |
40 |
> |
41 |
> I like the idea of the PYTHON_DEPEND variable and the option to |
42 |
> disable its addition to DEPEND and RDEPEND. That makes it simple to |
43 |
> control for packages which only need python for building, for example. |
44 |
> |
45 |
> I don't think we really need the switch you mention for controlling |
46 |
> optional python dependencies, but I guess it couldn't hurt. |
47 |
> |
48 |
> > 4. Finally, provide a general, parametrized dependency generator |
49 |
> > function which will be useful in all the remaining non-common cases |
50 |
> > which can't be handled sanely by any other solution. |
51 |
> > |
52 |
> |
53 |
> Sounds good to me. We should hash out exactly what parameters it would |
54 |
> take; hopefully we can make it flexible enough to deal with changes in |
55 |
> dependency atoms in future EAPIs. |
56 |
> |
57 |
> As I interpret your example, your hypothetical function takes a list |
58 |
> of use flags as $1, and the rest of the parameters are python targets. |
59 |
> Maybe we should put the use flag list behind a switch? I'm mainly |
60 |
> thinking of scenarios where various python implementations support |
61 |
> different use flags. |
62 |
|
63 |
I'm not sure about this flag list. I have put a bit of thought and I've |
64 |
come to the following conclusion: |
65 |
|
66 |
1) If a particular Python version doesn't support a particular feature, |
67 |
then it can't go into supported implementations because it is |
68 |
pointless. |
69 |
|
70 |
If the feature is conditional it's really hard to say what to do. We |
71 |
could use REQUIRED_USE to make it a bit more sensible but it's, well, |
72 |
weird if you installed a package for three variants of Python and only |
73 |
two of them have a particular feature you have enabled. |
74 |
|
75 |
2) If a particular Python version does support the feature |
76 |
unconditionally, flag(+) is probably enough. |
77 |
|
78 |
Am I missing something? |
79 |
|
80 |
-- |
81 |
Best regards, |
82 |
Michał Górny |