* [gentoo-python] [PATCH] Introduce python_setup() as a common name for Python setup function.
@ 2013-10-20 7:36 Michał Górny
2013-10-20 14:53 ` Mike Gilbert
2013-10-22 15:18 ` Michał Górny
0 siblings, 2 replies; 7+ messages in thread
From: Michał Górny @ 2013-10-20 7:36 UTC (permalink / raw
To: gentoo-python; +Cc: 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:
--
1.8.4
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [gentoo-python] [PATCH] Introduce python_setup() as a common name for Python setup function.
2013-10-20 7:36 [gentoo-python] [PATCH] Introduce python_setup() as a common name for Python setup function Michał Górny
@ 2013-10-20 14:53 ` Mike Gilbert
2013-10-20 15:12 ` Michał Górny
2013-10-22 15:18 ` Michał Górny
1 sibling, 1 reply; 7+ messages in thread
From: Mike Gilbert @ 2013-10-20 14:53 UTC (permalink / raw
To: Michał Górny; +Cc: gentoo-python
On Sun, Oct 20, 2013 at 3:36 AM, Michał Górny <mgorny@gentoo.org> wrote:
> 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.
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [gentoo-python] [PATCH] Introduce python_setup() as a common name for Python setup function.
2013-10-20 14:53 ` Mike Gilbert
@ 2013-10-20 15:12 ` Michał Górny
2013-10-20 15:33 ` Mike Gilbert
0 siblings, 1 reply; 7+ messages in thread
From: Michał Górny @ 2013-10-20 15:12 UTC (permalink / raw
To: Mike Gilbert; +Cc: gentoo-python
[-- Attachment #1: Type: text/plain, Size: 801 bytes --]
Dnia 2013-10-20, o godz. 10:53:34
Mike Gilbert <floppym@gentoo.org> napisał(a):
> On Sun, Oct 20, 2013 at 3:36 AM, Michał Górny <mgorny@gentoo.org> wrote:
> > 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.
>
> 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?
--
Best regards,
Michał Górny
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [gentoo-python] [PATCH] Introduce python_setup() as a common name for Python setup function.
2013-10-20 15:12 ` Michał Górny
@ 2013-10-20 15:33 ` Mike Gilbert
2013-10-20 15:47 ` Michał Górny
0 siblings, 1 reply; 7+ messages in thread
From: Mike Gilbert @ 2013-10-20 15:33 UTC (permalink / raw
To: Michał Górny; +Cc: gentoo-python
On Sun, Oct 20, 2013 at 11:12 AM, Michał Górny <mgorny@gentoo.org> wrote:
> Dnia 2013-10-20, o godz. 10:53:34
> Mike Gilbert <floppym@gentoo.org> napisał(a):
>
>> On Sun, Oct 20, 2013 at 3:36 AM, Michał Górny <mgorny@gentoo.org> wrote:
>> > 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.
>>
>> 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).
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [gentoo-python] [PATCH] Introduce python_setup() as a common name for Python setup function.
2013-10-20 15:33 ` Mike Gilbert
@ 2013-10-20 15:47 ` Michał Górny
2013-10-20 16:26 ` Mike Gilbert
0 siblings, 1 reply; 7+ messages in thread
From: Michał Górny @ 2013-10-20 15:47 UTC (permalink / raw
To: Mike Gilbert; +Cc: gentoo-python
[-- Attachment #1: Type: text/plain, Size: 1586 bytes --]
Dnia 2013-10-20, o godz. 11:33:45
Mike Gilbert <floppym@gentoo.org> napisał(a):
> On Sun, Oct 20, 2013 at 11:12 AM, Michał Górny <mgorny@gentoo.org> wrote:
> > Dnia 2013-10-20, o godz. 10:53:34
> > Mike Gilbert <floppym@gentoo.org> napisał(a):
> >
> >> On Sun, Oct 20, 2013 at 3:36 AM, Michał Górny <mgorny@gentoo.org> wrote:
> >> > 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.
> >>
> >> 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...
--
Best regards,
Michał Górny
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [gentoo-python] [PATCH] Introduce python_setup() as a common name for Python setup function.
2013-10-20 15:47 ` Michał Górny
@ 2013-10-20 16:26 ` Mike Gilbert
0 siblings, 0 replies; 7+ messages in thread
From: Mike Gilbert @ 2013-10-20 16:26 UTC (permalink / raw
To: Michał Górny; +Cc: gentoo-python
On Sun, Oct 20, 2013 at 11:47 AM, Michał Górny <mgorny@gentoo.org> wrote:
> Dnia 2013-10-20, o godz. 11:33:45
> Mike Gilbert <floppym@gentoo.org> napisał(a):
>
>> On Sun, Oct 20, 2013 at 11:12 AM, Michał Górny <mgorny@gentoo.org> wrote:
>> > Dnia 2013-10-20, o godz. 10:53:34
>> > Mike Gilbert <floppym@gentoo.org> napisał(a):
>> >
>> >> On Sun, Oct 20, 2013 at 3:36 AM, Michał Górny <mgorny@gentoo.org> wrote:
>> >> > 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.
>> >>
>> >> 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. ^_^
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [gentoo-python] [PATCH] Introduce python_setup() as a common name for Python setup function.
2013-10-20 7:36 [gentoo-python] [PATCH] Introduce python_setup() as a common name for Python setup function Michał Górny
2013-10-20 14:53 ` Mike Gilbert
@ 2013-10-22 15:18 ` Michał Górny
1 sibling, 0 replies; 7+ messages in thread
From: Michał Górny @ 2013-10-22 15:18 UTC (permalink / raw
To: Michał Górny; +Cc: gentoo-python
[-- Attachment #1: Type: text/plain, Size: 508 bytes --]
Dnia 2013-10-20, o godz. 09:36:46
Michał Górny <mgorny@gentoo.org> napisał(a):
> 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.
Committed.
--
Best regards,
Michał Górny
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2013-10-22 15:19 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-10-20 7:36 [gentoo-python] [PATCH] Introduce python_setup() as a common name for Python setup function Michał Górny
2013-10-20 14:53 ` Mike Gilbert
2013-10-20 15:12 ` Michał Górny
2013-10-20 15:33 ` Mike Gilbert
2013-10-20 15:47 ` Michał Górny
2013-10-20 16:26 ` Mike Gilbert
2013-10-22 15:18 ` Michał Górny
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox