Rather than hardcoding a list of "-p" arguments for various plugins,
iterate through entry points to find them. This should be quite
reliable, given that we require PN to match Python project names,
and we can add a mapping for the few outliers.
Suggested-by: Anna Vyalkova
See-also:
https://public-inbox.gentoo.org/gentoo-dev/[email protected]/T/#m3487af520bfaec9dbaba0ea800bb0aca5fb2fcdc
Signed-off-by: Michał Górny <
[email protected]>
---
eclass/python-utils-r1.eclass | 73 +++++++++--------------------------
1 file changed, 19 insertions(+), 54 deletions(-)
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass index 4ce75b962957..dce565b8b036 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -1288,9 +1288,9 @@ _python_check_occluded_packages() {
# Defaults to an empty list.
#
# The eclasses explicitly handle a number of pytest plugins, and assume
-# the default of "dev-python/${package}" and "-p ${package}" for others.
-# If this is incorrect for some plugin package, please report a bug
-# to have it added.
+# the default of "dev-python/${package}" and obtain "-p" via entry
+# points. If this is incorrect for some plugin package, please report
+# a bug.
#
# This is not a perfect solution, and may not be sufficient for some
# packages. In these cases, either plugin autoloading should be used
@@ -1441,57 +1441,22 @@ epytest() {
fi
if [[ ${PYTEST_DISA