1 |
I've just looked through python-distutils-ng again and I think it |
2 |
deserves at least a bit of changes, if not complete redesign. |
3 |
|
4 |
It is currently used by 22 packages in Gentoo, and probably a few |
5 |
in the overlays. I'd honestly prefer to avoid further packages doing |
6 |
that before we decide on how to proceed. That's why the first patch I'm |
7 |
suggesting somehow marks is as work-in-progress and asks people not to |
8 |
use it yet. |
9 |
|
10 |
The second and third patches just fix one of the formal problems. |
11 |
|
12 |
The fourth patch completely removes PYTHON_OPTIONAL support. It is not |
13 |
used by any of the mentioned packages right now and that way I'd like to |
14 |
avoid it being used by anything else, before we redesign it. |
15 |
|
16 |
The major issue I see with it is that it hardcodes the 'python' flag. |
17 |
That's a bit mistaken, I believe. Not that I see much use for |
18 |
an optional Python support in package using distutils, and if there is |
19 |
one, I believe developers will find it more comfortable to do: |
20 |
|
21 |
use python && python-distutils-ng_src_compile |
22 |
|
23 |
than expect the eclass to do that check for them. |
24 |
|
25 |
We also should think about USE-dependencies more (I will think about it |
26 |
myself, trying to find some working solution better than one suggested |
27 |
by Arfrever [the <<[use]>>]). It will be hard thinking... |
28 |
|
29 |
And one thing certainly needing discussing is extracting some |
30 |
common-python code to a separate eclass, without the distutils part. |
31 |
To be honest, I'd rather move the whole 'optionality' of Python there. |
32 |
|
33 |
And lastly, the name. Considering the amount of work that needs to be |
34 |
done, we might also decide to 'lastrite' the eclass and work on a new |
35 |
one, replacing 'ng' with something saner. |