Re: [gentoo-dev] [PATCH python-r1] Move common utility functions to python-utils-r1.

2012-11-23 Thread Michał Górny 
On Fri, 23 Nov 2012 08:06:55 +0100
Rémi Cardona  wrote:

> Le jeudi 22 novembre 2012 à 20:59 +0100, Michał Górny a écrit :
> 
> > You could say it's an algo like this:
> > 
> > 1) if you want phase functions for distutils & all other automagic,
> >use distutils-r1;
> > 
> > 2) if you don't want phase functions but want PYTHON_TARGETS and other
> >metadata stuff, use python-r1;
> > 
> > 3) if you don't want phase functions nor metadata, just some random
> >potentially useful functions, use python-utils-r1.
> 
> 
> Please, pretty please: paste this blurb somewhere (near the top) in
> *one* of the above three eclasses and modify the other 2 to point
> developers to the former eclass.

I'm working on the official text for python-r1 Developer's Guide. It
will be there when the eclasses are committed.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] [PATCH python-r1] Move common utility functions to python-utils-r1.

2012-11-22 Thread Rémi Cardona 
Le jeudi 22 novembre 2012 à 20:59 +0100, Michał Górny a écrit :

> You could say it's an algo like this:
> 
> 1) if you want phase functions for distutils & all other automagic,
>use distutils-r1;
> 
> 2) if you don't want phase functions but want PYTHON_TARGETS and other
>metadata stuff, use python-r1;
> 
> 3) if you don't want phase functions nor metadata, just some random
>potentially useful functions, use python-utils-r1.


Please, pretty please: paste this blurb somewhere (near the top) in
*one* of the above three eclasses and modify the other 2 to point
developers to the former eclass.

Cheers,

Rémi

Re: [gentoo-dev] [PATCH python-r1] Move common utility functions to python-utils-r1.

2012-11-22 Thread Michał Górny 
On Wed, 21 Nov 2012 10:30:29 -0500
Ian Stakenvicius  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 21/11/12 10:17 AM, Gilles Dartiguelongue wrote:
> > Le mercredi 21 novembre 2012 à 08:54 -0500, Ian Stakenvicius a
> > écrit :
> >> On 21/11/12 04:43 AM, Michał Górny wrote:
> >>> Moved: python_export, getters, python_domodule, python_doscript
> >>> and the necessary internal functions. No global-scope
> >>> variables, no phase functions. [ Snip! ]
> >> 
> >> So remind me again, in 10 words or less, why these shouldn't all
> >> stay in python-r1.eclass?  ie, what use case do we have for
> >> using python-utils-r1 but not python-r1 (or vice-versa, depending
> >> on which one inherits the other)?
> > 
> > From "[gentoo-dev] python-r1.eclass: the masterplan (dirty RFC)"
> > email:
> > 
> > Le lundi 12 novembre 2012 à 15:43 +0100, Michał Górny a écrit :
> >> 1) splitting common functions into python-utils-r1.
> >> 
> >> The python-utils-r1 eclass would provide means to work with
> >> specific Python packages like portage. Unlike python-r1, it would
> >> not export IUSE or require any specific USE flags.
> >> 
> >> I'm not insisting on this nor giving it a very high priority. It
> >> is a straightforward change since python-r1 will inherit the new
> >> eclass anyway.
> > 
> > 
> 
> 
> Ahh ok, so only very specific tools for very specific use cases.

You could say it's an algo like this:

1) if you want phase functions for distutils & all other automagic,
   use distutils-r1;

2) if you don't want phase functions but want PYTHON_TARGETS and other
   metadata stuff, use python-r1;

3) if you don't want phase functions nor metadata, just some random
   potentially useful functions, use python-utils-r1.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] [PATCH python-r1] Move common utility functions to python-utils-r1.

2012-11-21 Thread Ian Stakenvicius 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 21/11/12 10:17 AM, Gilles Dartiguelongue wrote:
> Le mercredi 21 novembre 2012 à 08:54 -0500, Ian Stakenvicius a
> écrit :
>> On 21/11/12 04:43 AM, Michał Górny wrote:
>>> Moved: python_export, getters, python_domodule, python_doscript
>>> and the necessary internal functions. No global-scope
>>> variables, no phase functions. [ Snip! ]
>> 
>> So remind me again, in 10 words or less, why these shouldn't all
>> stay in python-r1.eclass?  ie, what use case do we have for
>> using python-utils-r1 but not python-r1 (or vice-versa, depending
>> on which one inherits the other)?
> 
> From "[gentoo-dev] python-r1.eclass: the masterplan (dirty RFC)"
> email:
> 
> Le lundi 12 novembre 2012 à 15:43 +0100, Michał Górny a écrit :
>> 1) splitting common functions into python-utils-r1.
>> 
>> The python-utils-r1 eclass would provide means to work with
>> specific Python packages like portage. Unlike python-r1, it would
>> not export IUSE or require any specific USE flags.
>> 
>> I'm not insisting on this nor giving it a very high priority. It
>> is a straightforward change since python-r1 will inherit the new
>> eclass anyway.
> 
> 


Ahh ok, so only very specific tools for very specific use cases.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlCs85UACgkQ2ugaI38ACPCxHwD9FvHW2Ke/lcsTDomAIOpEqreH
Vo6YDYUeDTm2GlBhA4cA/1yG0Fkh+7MNBZc31naOAvL7rh51Xhj8KxHHDuPsfKyC
=qsUS
-END PGP SIGNATURE-

Re: [gentoo-dev] [PATCH python-r1] Move common utility functions to python-utils-r1.

2012-11-21 Thread Gilles Dartiguelongue 
Le mercredi 21 novembre 2012 à 08:54 -0500, Ian Stakenvicius a écrit :
> On 21/11/12 04:43 AM, Michał Górny wrote:
> > Moved: python_export, getters, python_domodule, python_doscript and
> > the necessary internal functions. No global-scope variables, no
> > phase functions. [ Snip! ]
> 
> So remind me again, in 10 words or less, why these shouldn't all stay
> in python-r1.eclass?  ie, what use case do we have for using
> python-utils-r1 but not python-r1 (or vice-versa, depending on which
> one inherits the other)?

>From "[gentoo-dev] python-r1.eclass: the masterplan (dirty RFC)" email:

Le lundi 12 novembre 2012 à 15:43 +0100, Michał Górny a écrit :
> 1) splitting common functions into python-utils-r1.
> 
> The python-utils-r1 eclass would provide means to work with specific
> Python packages like portage. Unlike python-r1, it would not export
> IUSE or require any specific USE flags.
> 
> I'm not insisting on this nor giving it a very high priority. It is
> a straightforward change since python-r1 will inherit the new eclass
> anyway.

Re: [gentoo-dev] [PATCH python-r1] Move common utility functions to python-utils-r1.

2012-11-21 Thread Ian Stakenvicius 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 21/11/12 04:43 AM, Michał Górny wrote:
> Moved: python_export, getters, python_domodule, python_doscript and
> the necessary internal functions. No global-scope variables, no
> phase functions. [ Snip! ]

So remind me again, in 10 words or less, why these shouldn't all stay
in python-r1.eclass?  ie, what use case do we have for using
python-utils-r1 but not python-r1 (or vice-versa, depending on which
one inherits the other)?





-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlCs3RIACgkQ2ugaI38ACPBDlgEAq70QL+M5jDtM8zcUJs4y0bkp
fDpQaPIzy6KCvM0e6S8A/iCB2yTSimQimegtIVwUE9RrLLSyifd+IljGP/6xvksB
=Kebg
-END PGP SIGNATURE-

[gentoo-dev] [PATCH python-r1] Move common utility functions to python-utils-r1.

2012-11-21 Thread Michał Górny 
Moved: python_export, getters, python_domodule, python_doscript
and the necessary internal functions. No global-scope variables,
no phase functions.
---
 gx86/eclass/python-r1.eclass   | 409 +-
 gx86/eclass/python-utils-r1.eclass | 434 +
 2 files changed, 440 insertions(+), 403 deletions(-)
 create mode 100644 gx86/eclass/python-utils-r1.eclass

diff --git a/gx86/eclass/python-r1.eclass b/gx86/eclass/python-r1.eclass
index 84dc50f..6cf4200 100644
--- a/gx86/eclass/python-r1.eclass
+++ b/gx86/eclass/python-r1.eclass
@@ -23,6 +23,11 @@
 # Please note that this eclass is mostly intended to be extended
 # on-request. If you find something you used in other eclasses missing,
 # please don't hack it around and request an enhancement instead.
+#
+# Also, please note that python-r1 will always inherit python-utils-r1
+# as well. Thus, all the functions defined and documented there
+# can be used in the packages using python-r1, and there is no need ever
+# to inherit both.
 
 case "${EAPI}" in
0|1|2|3)
@@ -36,7 +41,7 @@ case "${EAPI}" in
;;
 esac
 
-inherit multilib
+inherit python-utils-r1
 
 # @ECLASS-VARIABLE: _PYTHON_ALL_IMPLS
 # @INTERNAL
@@ -181,160 +186,6 @@ _python_set_globals
 # ${WORKDIR}/foo-1.3-python2_6
 # @CODE
 
-# @ECLASS-VARIABLE: PYTHON
-# @DESCRIPTION:
-# The absolute path to the current Python interpreter.
-#
-# Set and exported only in commands run by python_foreach_impl().
-#
-# Example value:
-# @CODE
-# /usr/bin/python2.6
-# @CODE
-
-# @ECLASS-VARIABLE: EPYTHON
-# @DESCRIPTION:
-# The executable name of the current Python interpreter.
-#
-# This variable is used consistently with python.eclass.
-#
-# Set and exported only in commands run by python_foreach_impl().
-#
-# Example value:
-# @CODE
-# python2.6
-# @CODE
-
-# @ECLASS-VARIABLE: PYTHON_SITEDIR
-# @DESCRIPTION:
-# The path to Python site-packages directory.
-#
-# Set and exported on request using python_export().
-#
-# Example value:
-# @CODE
-# /usr/lib64/python2.6/site-packages
-# @CODE
-
-# @FUNCTION: python_export
-# @USAGE: [] ...
-# @DESCRIPTION:
-# Set and export the Python implementation-relevant variables passed
-# as parameters.
-#
-# The optional first parameter may specify the requested Python
-# implementation (either as PYTHON_TARGETS value, e.g. python2_7,
-# or an EPYTHON one, e.g. python2.7). If no implementation passed,
-# the current one will be obtained from ${EPYTHON}.
-#
-# The variables which can be exported are: PYTHON, EPYTHON,
-# PYTHON_SITEDIR. They are described more completely in the eclass
-# variable documentation.
-python_export() {
-   debug-print-function ${FUNCNAME} "${@}"
-
-   local impl var
-
-   case "${1}" in
-   python*|jython*)
-   impl=${1/_/.}
-   shift
-   ;;
-   pypy-c*)
-   impl=${1}
-   shift
-   ;;
-   pypy*)
-   local v=${1#pypy}
-   impl=pypy-c${v/_/.}
-   shift
-   ;;
-   *)
-   impl=${EPYTHON}
-   [[ ${impl} ]] || die "python_export: no impl nor 
EPYTHON"
-   ;;
-   esac
-   debug-print "${FUNCNAME}: implementation: ${impl}"
-
-   for var; do
-   case "${var}" in
-   EPYTHON)
-   export EPYTHON=${impl}
-   debug-print "${FUNCNAME}: EPYTHON = ${EPYTHON}"
-   ;;
-   PYTHON)
-   export PYTHON=${EPREFIX}/usr/bin/${impl}
-   debug-print "${FUNCNAME}: PYTHON = ${PYTHON}"
-   ;;
-   PYTHON_SITEDIR)
-   local dir
-   case "${impl}" in
-   python*)
-   dir=/usr/$(get_libdir)/${impl}
-   ;;
-   jython*)
-   dir=/usr/share/${impl}/Lib
-   ;;
-   pypy*)
-   
dir=/usr/$(get_libdir)/${impl/-c/}
-   ;;
-   esac
-
-   export 
PYTHON_SITEDIR=${EPREFIX}${dir}/site-packages
-   debug-print "${FUNCNAME}: PYTHON_SITEDIR = 
${PYTHON_SITEDIR}"
-   ;;
-   *)
-   die "python_export: unknown variable ${var}"
-   esac
-   done
-}
-
-# @FUNCTION: python_get_PYTH