Sometimes a package calls python-any-r1_pkg_setup unconditionally (usually by not defining pkg_setup at all) even though they have BDEPEND="test? ( ${PYTHON_DEPS} )" (or some other USE flag).
This can cause build failures as the eclass will check for the existence of a valid interpreter but one may not exist as the dependency doesn't guarantee it.
From #401 (comment):
Could this work for a simple package using e.g. python-any-r1, putting ${PYTHON_DEPS} in *DEPEND under a USE flag, but not defining pkg_setup?
Example I'm thinking of is app-admin/github-backup-utils:
# Python3 support: https://github.com/github/backup-utils/pull/627
PYTHON_COMPAT=( python3_{8..10} )
inherit python-any-r1
DESCRIPTION="Backup and recovery utilities for GitHub Enterprise"
HOMEPAGE="https://github.com/github/backup-utils"
SRC_URI="https://github.com/github/backup-utils/archive/v${PV}.tar.gz -> ${P}.tar.gz"
LICENSE="MIT"
SLOT="0"
KEYWORDS="~amd64"
IUSE="test"
RESTRICT="!test? ( test )"
# moreutils parallel is now used for speedups in main code:
# https://github.com/github/backup-utils/pull/635
RDEPEND="app-misc/jq
app-archive/pigz
net-misc/rsync
sys-apps/moreutils"
# tests invoke parallel & rsync
DEPEND="test? (
${RDEPEND}
dev-util/checkbashisms
${PYTHON_DEPS}
)"
[...]
src_compile() {
:;
}
[...]
python-any-r1_pkg_setup is unconditionally called despite the dependency only being guaranteed for tests. This can cause issues if upgrading an older system because Portage is free to queue this package before newer Python versions, but after python-exec. pkg_setup may then fail because it's unconditionally checking for Python, but no usable/modern enough interpreter is yet installed (or python-exec not yet re-emerged with right flags/upgraded), so the check will fail, and bomb out emerge entirely, and may not be relaunchable (this has happened a number of times in #gentoo, it happens with packages calling 'python' directly too because they'll fail and hit a python-exec error).
Sometimes a package calls python-any-r1_pkg_setup unconditionally (usually by not defining pkg_setup at all) even though they have BDEPEND="test? ( ${PYTHON_DEPS} )" (or some other USE flag).
This can cause build failures as the eclass will check for the existence of a valid interpreter but one may not exist as the dependency doesn't guarantee it.
From #401 (comment):