On Wed, 21 Nov 2012 10:30:29 -0500 Ian Stakenvicius <a...@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
signature.asc
Description: PGP signature
