On Wed, 21 Nov 2012 10:30:29 -0500
Ian Stakenvicius <axs@gentoo.org> 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