[PATCH] Introduce python_setup() as a common name for Python setup function.

[Michał Górny]

As described in the ml, the new function does:

* in python-any-r1, choose and set up the best installed impl,

* in python-single-r1, read PYTHON_SINGLE_TARGET and set it up,

* in python-r1, call python_export_best + python_wrapper_setup.

In other words, it's a common way of getting Python build environment
set up in the ebuild scope.
---
eclass/python-any-r1.eclass | 24 +++++++++++++++++-------
eclass/python-r1.eclass | 15 +++++++++++++++
eclass/python-single-r1.eclass | 17 +++++++++++++----
3 files changed, 45 insertions(+), 11 deletions(-)

diff --git a/eclass/python-any-r1.eclass b/eclass/python-any-r1.eclass
index 760e8e7..109c4ee 100644
--- a/eclass/python-any-r1.eclass
+++ b/eclass/python-any-r1.eclass
@@ -259,17 +259,15 @@ _python_EPYTHON_supported() {
return 1
}

-# @FUNCTION: python-any-r1_pkg_setup
+# @FUNCTION: python_setup
# @DESCRIPTION:
# Determine what the best installed (and supported) Python
-# implementation is and set EPYTHON and PYTHON accordingly.
-python-any-r1_pkg_setup() {
+# implementation is, and set the Python build environment up for it.
+#
+# This function will call python_check_deps() if defined.
+python_setup() {
debug-print-function ${FUNCNAME} "${@}"

- # avoid looking up Python for binary package install.
- # if you need Python during pkg_preinst/_postinst, please let us know.
- [[ ${MERGE_TYPE} == binary ]] && return 0
-
# first, try ${EPYTHON}... maybe it's good enough for us.
if [[ ${EPYTHON} ]]; then
if _python_EPYTHON_supported "${EPYTHON}"; then
@@ -317,5 +315,17 @@ python-any-r1_pkg_setup() {
die "No supported Python implementation installed."
}

+# @FUNCTION: python-any-r1_pkg_setup
+# @DESCRIPTION:
+# Runs python_setup during from-source installs.
+#
+# In a binary package installs is a no-op. If you need Python in pkg_*
+# phases of a binary package, call python_setup directly.
+python-any-r1_pkg_setup() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+ [[ ${MERGE_TYPE} != binary ]] && python_setup
+}
+
_PYTHON_ANY_R1=1
fi
diff --git a/eclass/python-r1.eclass b/eclass/python-r1.eclass
index 750fa91..1a04d5b 100644
--- a/eclass/python-r1.eclass
+++ b/eclass/python-r1.eclass
@@ -712,6 +712,21 @@ python_parallel_foreach_impl() {
multibuild_parallel_foreach_variant _python_multibuild_wrapper "${@}"
}

+# @FUNCTION: python_setup
+# @DESCRIPTION:
+# Find the best (most preferred) Python implementation enabled
+# and set the Python build environment up for it.
+#
+# This function needs to be used when Python is being called outside
+# of python_foreach_impl calls (e.g. for shared processes like doc
+# building). python_foreach_impl sets up the build environment itself.
+python_setup() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+ python_export_best
+ python_wrapper_setup
+}
+
# @FUNCTION: python_export_best
# @USAGE: [<variable>...]
# @DESCRIPTION:
diff --git a/eclass/python-single-r1.eclass b/eclass/python-single-r1.eclass
index 30bbab4..5ff3d40 100644
--- a/eclass/python-single-r1.eclass
+++ b/eclass/python-single-r1.eclass
@@ -202,11 +202,11 @@ _python_single_set_globals() {
}
_python_single_set_globals

-# @FUNCTION: python-single-r1_pkg_setup
+# @FUNCTION: python_setup
# @DESCRIPTION:
-# Determine what the selected Python implementation is and set EPYTHON
-# and PYTHON accordingly.
-python-single-r1_pkg_setup() {
+# Determine what the selected Python implementation is and set
+# the Python build environment up for it.
+python_setup() {
debug-print-function ${FUNCNAME} "${@}"

unset EPYTHON
@@ -250,6 +250,15 @@ python-single-r1_pkg_setup() {
fi
}

+# @FUNCTION: python-single-r1_pkg_setup
+# @DESCRIPTION:
+# Runs python_setup.
+python-single-r1_pkg_setup() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+ python_setup
+}
+
# @FUNCTION: python_fix_shebang
# @USAGE: <path>...
# @DESCRIPTION:

[Mike Gilbert]

Post by Michał Górny
* in python-any-r1, choose and set up the best installed impl,
* in python-single-r1, read PYTHON_SINGLE_TARGET and set it up,
* in python-r1, call python_export_best + python_wrapper_setup.
In other words, it's a common way of getting Python build environment
set up in the ebuild scope.

Invoking python_setup from pkg_setup in any eclass seems sub-optimal;
especially so in python-any-r1. However, I realize there isn't a great
place to put it.

Looks ok to me.

[Michał Górny]

Dnia 2013-10-20, o godz. 10:53:34

Post by Mike Gilbert

Post by Michał Górny
* in python-any-r1, choose and set up the best installed impl,
* in python-single-r1, read PYTHON_SINGLE_TARGET and set it up,
* in python-r1, call python_export_best + python_wrapper_setup.
In other words, it's a common way of getting Python build environment
set up in the ebuild scope.

Invoking python_setup from pkg_setup in any eclass seems sub-optimal;
especially so in python-any-r1. However, I realize there isn't a great
place to put it.

I don't understand. Could you rephrase?

[Mike Gilbert]

Post by Michał Górny
Dnia 2013-10-20, o godz. 10:53:34

Post by Mike Gilbert

Post by Michał Górny
* in python-any-r1, choose and set up the best installed impl,
* in python-single-r1, read PYTHON_SINGLE_TARGET and set it up,
* in python-r1, call python_export_best + python_wrapper_setup.
In other words, it's a common way of getting Python build environment
set up in the ebuild scope.

Invoking python_setup from pkg_setup in any eclass seems sub-optimal;
especially so in python-any-r1. However, I realize there isn't a great
place to put it.

I don't understand. Could you rephrase?

The python stuff is generally only used in "src" phases, so pkg_setup
is the wrong place for it.. As well, it would be better to set up the
python wrappers and environment in a phase where the sandbox and
userpriv are active to prevent permissions problems like we had with
Paludis recently (there's a bug, but I'm not going to look for it).

[Michał Górny]

Dnia 2013-10-20, o godz. 11:33:45

Post by Mike Gilbert

Post by Michał Górny
Dnia 2013-10-20, o godz. 10:53:34

Post by Mike Gilbert

Post by Michał Górny
* in python-any-r1, choose and set up the best installed impl,
* in python-single-r1, read PYTHON_SINGLE_TARGET and set it up,
* in python-r1, call python_export_best + python_wrapper_setup.
In other words, it's a common way of getting Python build environment
set up in the ebuild scope.

Invoking python_setup from pkg_setup in any eclass seems sub-optimal;
especially so in python-any-r1. However, I realize there isn't a great
place to put it.

I don't understand. Could you rephrase?

The python stuff is generally only used in "src" phases, so pkg_setup
is the wrong place for it.. As well, it would be better to set up the
python wrappers and environment in a phase where the sandbox and
userpriv are active to prevent permissions problems like we had with
Paludis recently (there's a bug, but I'm not going to look for it).

I can understand you but can't really think of a good way of doing
this. The only other reasonable phase for this is src_prepare(),
and overriding it will result in hell breaking loose...

[Mike Gilbert]

Post by Michał Górny
Dnia 2013-10-20, o godz. 11:33:45

Post by Mike Gilbert

Post by Michał Górny
Dnia 2013-10-20, o godz. 10:53:34

Post by Mike Gilbert

Post by Michał Górny
* in python-any-r1, choose and set up the best installed impl,
* in python-single-r1, read PYTHON_SINGLE_TARGET and set it up,
* in python-r1, call python_export_best + python_wrapper_setup.
In other words, it's a common way of getting Python build environment
set up in the ebuild scope.

Invoking python_setup from pkg_setup in any eclass seems sub-optimal;
especially so in python-any-r1. However, I realize there isn't a great
place to put it.

I don't understand. Could you rephrase?

The python stuff is generally only used in "src" phases, so pkg_setup
is the wrong place for it.. As well, it would be better to set up the
python wrappers and environment in a phase where the sandbox and
userpriv are active to prevent permissions problems like we had with
Paludis recently (there's a bug, but I'm not going to look for it).

I can understand you but can't really think of a good way of doing
this. The only other reasonable phase for this is src_prepare(),
and overriding it will result in hell breaking loose...

Right. I just wanted to go "on the record" as saying that this is not
optimal, but there is probably no better alternative. Carry on. ^_^

[Michał Górny]

Dnia 2013-10-20, o godz. 09:36:46

Post by Michał Górny
* in python-any-r1, choose and set up the best installed impl,
* in python-single-r1, read PYTHON_SINGLE_TARGET and set it up,
* in python-r1, call python_export_best + python_wrapper_setup.
In other words, it's a common way of getting Python build environment
set up in the ebuild scope.

Committed.