Friends! The current state of python-single-r1 bothered me a lot lately, and while _AxS_ did some neat improvements to the eclass, it's still far from perfect solution to our users.
The PYTHON_SINGLE_TARGET flags were added to make it easier to handle single-impl packages that support both Python 2 & Python 3 which we enable both in our profiles. It serves that purpose well -- however, it isn't that good for single-impl packages that don't support the most common choice of implementations. In particular, it has two major issues: 1. We have no sane, clear and universal way of providing users with sensible defaults. It's always one trade-off over another. 2. Matching USE dependencies against multi-impl packages introduces a second set of USE flags (PYTHON_TARGETS) that are semi-virtual. Sadly, they introduce confusion and cause issues. As far as the first issue is concerned, I think enough has been said already. Right now we are fine-tuned for two cases: a. packages that support one impl only -- then they have a single PYTHON_TARGET that's enabled by default, b. packages that support python2.7 -- then we have the profile default of python2.7 for them. We have no good way of handling packages that support Python 3 only. The other issue comes into game in two cases I've seen: A. when we try to improve setting of PYTHON_SINGLE_TARGET, we force the user to enable matching PYTHON_TARGET anyway -- so in the end manual intervention is required, B. they cause issues with REQUIRED_USE on other packages (like libpeas that supports only one version of python2 and one of python3). Even though PYTHON_SINGLE_TARGET results in effective use of a single impl, PYTHON_TARGET USE-dep requests full PYTHON_TARGETS match on the dep. Therefore, the user needs to disable other implementations anyway to get the expected result. To be honest, I don't see a good way out of this. Possible bad ways: I. disable PYTHON_SINGLE_TARGET and use PYTHON_REQUIRED_USE="^^ ..." when python2_7 is not in PYTHON_COMPAT. In other words, add another workaround that gets things rolling with the default profile setup. II. Remove PYTHON_SINGLE_TARGET completely and use PYTHON_REQUIRED_USE="^^ ...". Option (1) is 'uglier' since it introduces another special case and adds to the complexity. However, it supposedly impacts the lowest number of users -- the default profile settings should pass, and only people enabling more implementations would have to disable the flags. Option (2) is cleaner but it imposes a major shock to our users. It specifically involves manipulating USE flags on a lot of packages even with the default profiles. Both options come with another major drawback -- exactly-one-if deps force manipulating the flags. Once manipulation is done, it may make Python upgrades much harder -- esp. if portage would end up enabling older impls via p.use. Of course, this wouldn't be a problem if users only added -flags to disable the old implementations. Then the issue will reapply when a new implementation is enabled globally, making the effective of 2 enabled implementations. So, what are your thoughts? What are your solutions? -- Best regards, Michał Górny
signature.asc
Description: PGP signature
