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.
