Currently the portage ebuild (that is, the standard Gentoo ebuild for the sys-apps/portage application in the tree formerly known as gentoo-x86) has a dependency like: DEPEND="apidoc? ( dev-python/sphinx dev-python/sphinx-epytext )" which fails to capture the requirement that dev-python/sphinx-epytext needs to be built against the same python that will be used by the sys-apps/portage ebuild to process the api documentation. Otherwise the standard "emerge sys-apps/portage" can crash pretty easily. As an example, this just failed for me. What I (think) occured: o I formerly had apidoc useflag disabled (now I enabled) o I had a bare dev-python/sphinx-epytext atom in @world o dev-python/sphinx PYTHON_TARGETS was exactly: "python3_7 python3_8" o sys-apps/portage PYTHON_TARGETS was exactly: "python3_7 python3_8" o dev-python/sphinx-epytext PYTHON_TARGETS was* exactly "python3_7" (I'm guessing that) sys-apps/portage ebuild tried to build apidoc during python_install_all. Meaning, since in my sys-apps/portage, PYTHON_TARGETS USE_EXPAND is effectively "python3_7 python3_8", this used the python3_8 EPYTHON. But since nobody told me (the end-user) to enable the python_targets_python3_8 use-flag for the dev-python/sphinx-epytext ebuild, I got an ebuild crash during src_install (sphinx complained, no epytext installed). Kind of tricky... or maybe I'm just not thinking of an elegant way to do it. I can think of these solutions in order of increasing personal preference: o overspecify the sphinx-epytext requirement using all the portage impl's (but this will lead to falsely-irreconcilable PYTHON_TARGETS dependencies in sys-apps/portage, if at any time sphinx-epytext fails to support every python impl that portage supports) o A hand-coded fail & bail during pkg_setup. o use built_with_use (if that's still a thing?) to determine at run-time which PYTHON impl can be used to successfully build the apidocs, and move this out of All kinda suck. The '100% correct' solution, I guess, would be to somehow calculate the native python implementation during dep-solving and feed that to the DEP="$(python_gen_cond_dep 'dev-python/sphinx-epytext[${PYTHON_USEDEP}]' ${native_python})" ... if that's even legally doable? -- * disclaimer: This particular situation was due to pointless upgrade-cruft. But one could imagine a legit reason for an analogous config, either now, or, especially, in some plausible gentoo future.
(In reply to Greg Turner from comment #0) > o use built_with_use (if that's still a thing?) to determine at run-time > which PYTHON impl can be used to successfully build the apidocs, and move > this out of oops, meant to say, move this out of python_install_all and into python_install... or something like that.
hmm... see my complaint below about "should depend on dev-python/sphinx[${PYTHON_USEDEP}] dev-python/sphinx-epytext[${PYTHON_USEDEP}]". This means that the entire menu of PYTHON_COMPAT choices in sys-apps/portage must be brought to dev-python/sphinx{,-epytext} ebuilds. It just so happens that at the moment dev-python/sphinx and dev-python/portage have identical PYTHON_COMPAT. But already sphinx-epytext is missing pypy3, and honestly, the burden of keeping these all in sync seems too high given that ultimately, only a single python impl actually needs to work to get the job done. I'm guessing that's how things got this loose in the first place :) I think the way to cut this particular gordian knot is just to figure out, ahead of time* the "best" impl in the disjunction of the set of sphinx-epytext built-with-use impls** and currently-active (in portage ebuild) PYTHON_TARGETS. Best, here, I suppose, could be decided like by multibuild_for_best_variant. Geez, it's a bit scary, the more I think about it. Perhaps this kind of magic belongs in python-utils-r1.eclass alongside build_sphinx() or something. Or perhaps the "bug" is even more tolerable than any available solution...? -- *i.e., probably during pkg_setup (or maybe pkg_pretend? But I suspect it must be the former) **note that this alone should indirectly enforce any corresponding PYTHON_USEDEP-ish requirement in dev-python/sphinx via the standard usedep reverse-waterfall.
Pretty ancient + pretty obscure lookin'. It's as useful closed as open imo.
