| 1 |
Hello, all. |
| 2 |
|
| 3 |
If I recall correctly, jlec lately mentioned he'd like to use |
| 4 |
python-any-r1 and python-single-r1. A particularly inevitable use case |
| 5 |
for this would be ebuilds using waf, so I'll use that as an example. |
| 6 |
|
| 7 |
The idea is pretty simple. Since the ebuilds in question use waf that |
| 8 |
is in Python, the waf-utils.eclass inherits python-any-r1. However, |
| 9 |
some of the ebuilds may install Python modules as well, and that asks |
| 10 |
for python-single-r1. So the issue is how to make the two work together. |
| 11 |
|
| 12 |
|
| 13 |
Possible solution: hierarchical eclass overrides |
| 14 |
------------------------------------------------ |
| 15 |
|
| 16 |
Idea: if both python-any-r1 and python-single-r1 are inherited, |
| 17 |
the latter transparently overrides the former. More specifically, |
| 18 |
implementation selected for python-single-r1 is used for code designed |
| 19 |
for python-any-r1. |
| 20 |
|
| 21 |
Details: |
| 22 |
|
| 23 |
1. PYTHON_COMPAT is declared before the inherits, so it should be always |
| 24 |
set by ebuild. If we feel like the eclass needs to provide |
| 25 |
the default, it may only do so if ebuild doesn't set its own |
| 26 |
PYTHON_COMPAT. The eclass may also need to check ebuild's |
| 27 |
PYTHON_COMPAT for conflicts with own supported impls (and die in that |
| 28 |
case). |
| 29 |
|
| 30 |
2. PYTHON_REQ_USE likewise. The eclass may append to it (but careful |
| 31 |
with that). |
| 32 |
|
| 33 |
3. ${PYTHON_DEPS}: |
| 34 |
|
| 35 |
a. if python-single-r1 is inherited before python-any-r1 (waf-utils), |
| 36 |
PYTHON_DEPS is set by the former and the latter doesn't change |
| 37 |
it. Both waf-utils and the ebuild add PYTHON_DEPS, so the same |
| 38 |
deps get added twice but there's no functional difference from |
| 39 |
python-single-r1, |
| 40 |
|
| 41 |
b. if python-single-r1 is inherited after waf-utils, the latter adds |
| 42 |
dependency based on python-any-r1 and then the ebuild adds |
| 43 |
another based on python-single-r1. With a bit of luck or good |
| 44 |
programming, everything works fine. Worst case, additional |
| 45 |
version of Python may get pulled build-time as a result of |
| 46 |
any-of dep. |
| 47 |
|
| 48 |
4. python_setup() gets exported (overriden) by python-single-r1. Since |
| 49 |
it is called after the complete inherit chain, the correct version |
| 50 |
is used. |
| 51 |
|
| 52 |
5. python-any-r1_pkg_setup() just calls python-single-r1_pkg_setup(). |
| 53 |
|
| 54 |
6. python_check_deps() is not used. |
| 55 |
|
| 56 |
7. python_gen_any_dep() is an issue I don't know how to solve: |
| 57 |
|
| 58 |
a. if python-single-r1 is inherited before python-any-r1, it could |
| 59 |
override it so that it generates just a single dependency |
| 60 |
matching the syntax used for python-single-r1, |
| 61 |
|
| 62 |
b. but if waf-utils is inherited first, the dep strings will be |
| 63 |
generated before python-single-r1 is inherited, |
| 64 |
|
| 65 |
c. possibly we could just ban python_gen_any_dep() and make it |
| 66 |
export magical variable that will cause python-single-r1 inherit |
| 67 |
to die. |
| 68 |
|
| 69 |
|
| 70 |
Your thoughts? |
| 71 |
|
| 72 |
-- |
| 73 |
Best regards, |
| 74 |
Michał Górny |
Archives