| 1 |
Friends! |
| 2 |
|
| 3 |
The current state of python-single-r1 bothered me a lot lately, |
| 4 |
and while _AxS_ did some neat improvements to the eclass, it's still |
| 5 |
far from perfect solution to our users. |
| 6 |
|
| 7 |
The PYTHON_SINGLE_TARGET flags were added to make it easier to handle |
| 8 |
single-impl packages that support both Python 2 & Python 3 which we |
| 9 |
enable both in our profiles. It serves that purpose well -- however, it |
| 10 |
isn't that good for single-impl packages that don't support the most |
| 11 |
common choice of implementations. |
| 12 |
|
| 13 |
In particular, it has two major issues: |
| 14 |
|
| 15 |
1. We have no sane, clear and universal way of providing users with |
| 16 |
sensible defaults. It's always one trade-off over another. |
| 17 |
|
| 18 |
2. Matching USE dependencies against multi-impl packages introduces |
| 19 |
a second set of USE flags (PYTHON_TARGETS) that are semi-virtual. |
| 20 |
Sadly, they introduce confusion and cause issues. |
| 21 |
|
| 22 |
|
| 23 |
As far as the first issue is concerned, I think enough has been said |
| 24 |
already. Right now we are fine-tuned for two cases: |
| 25 |
|
| 26 |
a. packages that support one impl only -- then they have a single |
| 27 |
PYTHON_TARGET that's enabled by default, |
| 28 |
|
| 29 |
b. packages that support python2.7 -- then we have the profile default |
| 30 |
of python2.7 for them. |
| 31 |
|
| 32 |
We have no good way of handling packages that support Python 3 only. |
| 33 |
|
| 34 |
|
| 35 |
The other issue comes into game in two cases I've seen: |
| 36 |
|
| 37 |
A. when we try to improve setting of PYTHON_SINGLE_TARGET, we force |
| 38 |
the user to enable matching PYTHON_TARGET anyway -- so in the end |
| 39 |
manual intervention is required, |
| 40 |
|
| 41 |
B. they cause issues with REQUIRED_USE on other packages (like libpeas |
| 42 |
that supports only one version of python2 and one of python3). Even |
| 43 |
though PYTHON_SINGLE_TARGET results in effective use of a single impl, |
| 44 |
PYTHON_TARGET USE-dep requests full PYTHON_TARGETS match on the dep. |
| 45 |
Therefore, the user needs to disable other implementations anyway to |
| 46 |
get the expected result. |
| 47 |
|
| 48 |
|
| 49 |
To be honest, I don't see a good way out of this. Possible bad ways: |
| 50 |
|
| 51 |
I. disable PYTHON_SINGLE_TARGET and use PYTHON_REQUIRED_USE="^^ ..." |
| 52 |
when python2_7 is not in PYTHON_COMPAT. In other words, add another |
| 53 |
workaround that gets things rolling with the default profile setup. |
| 54 |
|
| 55 |
II. Remove PYTHON_SINGLE_TARGET completely and use |
| 56 |
PYTHON_REQUIRED_USE="^^ ...". |
| 57 |
|
| 58 |
Option (1) is 'uglier' since it introduces another special case |
| 59 |
and adds to the complexity. However, it supposedly impacts the lowest |
| 60 |
number of users -- the default profile settings should pass, and only |
| 61 |
people enabling more implementations would have to disable the flags. |
| 62 |
|
| 63 |
Option (2) is cleaner but it imposes a major shock to our users. It |
| 64 |
specifically involves manipulating USE flags on a lot of packages even |
| 65 |
with the default profiles. |
| 66 |
|
| 67 |
Both options come with another major drawback -- exactly-one-if deps |
| 68 |
force manipulating the flags. Once manipulation is done, it may make |
| 69 |
Python upgrades much harder -- esp. if portage would end up enabling |
| 70 |
older impls via p.use. |
| 71 |
|
| 72 |
Of course, this wouldn't be a problem if users only added -flags to |
| 73 |
disable the old implementations. Then the issue will reapply when a new |
| 74 |
implementation is enabled globally, making the effective of 2 enabled |
| 75 |
implementations. |
| 76 |
|
| 77 |
|
| 78 |
So, what are your thoughts? What are your solutions? |
| 79 |
|
| 80 |
-- |
| 81 |
Best regards, |
| 82 |
Michał Górny |
Archives