Le lundi 05 novembre 2012 à 16:48 -0800, Brian Harring a écrit :
>
> Either way, I'm honestly not trying to piss folks off here nor stop
> the efforts to dig us out of the python.eclass mess. That said,
> *this
> time around* that eclass should actually have a plan so that we don't
> wind up in the same cluster fuck scenario as prior.
I'm sure everyone understands that we want to avoid these eclass to be a
flying spaghetti monster again.
I am probably biased as I did not find using python.eclass that
difficult but I must admit the new one is much easier to understand at
least and for the case of distutils, really simple to use as I have
packaged a handful of pypi hosted packages in less than 5 minutes each.
So as a user of those eclasses and seeing the current code/patches I
think I can describe a bit what is intended, although I am not part of
the writing of it.
python-r1.eclass is intended to provide all necessary functions to help
building packages using python, be it pure-python or python bindings or
however you may need python.
It differs a lot from python.eclass in that in does not try to attempt
to define any phase which is imho fine as that would be better done by
another eclass more tied to the case being considered, autotools-python,
cmake-python, but I'm hypothesizing of the use I would do of it for
Gnome originated packages.
python-r1.eclass also wants to make things clear for package managers by
exposing the current selected python interpreter (or ABI if you prefer)
as USE_EXPAND flags. As already explained in other threads, this is very
similar to ruby.eclass and tentative multilib support and it appears to
be working decently fine.
As for the use of USE_PYTHON, I would guess that it was not reused to:
* not have to deal with backward compatibility
* avoid confusion wrt to USE_EXPAND behavior and result of mixing
USE_PYTHON definition that are not use flags at all
distutils-r1.eclass is a simple eclass using python-r1.eclass in order
to build any python package relying on setuptools/distutils. Basically,
you should not need to do more than:
EAPI=bla
PYTHON_COMPAT=( mylist )
inherit distutils-r1
and you are done. If someone wants to check how it looks like for real
world examples, check for rq-* ebuilds in my dev overlay.
Feel free to stab me if I telling atrocities or ask more details if that
looks insufficient, I'm sure this will help draft the roadmap and/or
enhance eclass documentation you'd like to see.
--
Gilles Dartiguelongue <e...@gentoo.org>
Gentoo
