1 |
Hello, |
2 |
|
3 |
The current design for getting the 'best implementation' is far from |
4 |
pretty. It pretty much relies on constant preference order, setting |
5 |
Python 2.7 over other implementations for practical reasons. As a side |
6 |
effect, various ebuilds rely on that particular order, e.g.: |
7 |
|
8 |
DEPEND="doc? ( dev-python/epydoc[$(python_gen_usedep 'python2*')] )" |
9 |
REQUIRED_USE="doc? ( $(python_gen_useflags 'python2*') )" |
10 |
|
11 |
which pretty much assumes that *if python2 is enabled*, then any |
12 |
version of it will be the best impl. I find this disgusting, and I'd |
13 |
like to replace it with something more explicit. |
14 |
|
15 |
|
16 |
Specifically: |
17 |
|
18 |
1. python_export_best becomes deprecated for good, |
19 |
|
20 |
2. python_setup changes API to: |
21 |
|
22 |
python_setup [<impl-wildcard>...] |
23 |
|
24 |
alike python_gen_* functions, defaulting to '*'. Now it chooses |
25 |
the best impl from implementations matching the specified patterns, |
26 |
e.g.: |
27 |
|
28 |
python_setup 'python2*' |
29 |
|
30 |
would get the best version of CPython 2. |
31 |
|
32 |
3. we introduce extra variable for distutils-r1 (oh cruel world, how |
33 |
should we name it?!) that applies wildcards to python_*_all() phases. |
34 |
|
35 |
|
36 |
As for the choice within the list the algo needs to stay as-is for now. |
37 |
However, in the future we could either: |
38 |
|
39 |
a. respect EPYTHON and fallback to the other algo, |
40 |
|
41 |
b. respect pre-defined order i.e. 3.4 > 2.7, |
42 |
|
43 |
c. respect the order in PYTHON_COMPAT -- however that could be a little |
44 |
surprising to devs. |
45 |
|
46 |
|
47 |
What are your thoughts? |
48 |
|
49 |
-- |
50 |
Best regards, |
51 |
Michał Górny |