| 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 |
Archives