On Mon, Jun 27, 2011 at 7:58 AM, Dirkjan Ochtman <firstname.lastname@example.org> wrote:
> Hi guys,
> So I know a bunch of people have already looked at it, and I'd like to
> know: what do you find better about the Ruby approach compared to the
> Python approach? Is it just the size of python.eclass, or are there a
> number of other issues?
Let´s start by agreeing with the complexity of the Python eclass. And
a heavy change right now, is going to be painful to say the least
because a great deal of packages have been adapted to work the way the
eclass works right now.
I agree with Grobian in what he said about the coding style of the
python.eclass, and would love to see that "fixed". I also agree with
the redundancy of some variables and I think just using PYTHON_DEPEND
should be sufficient to let the PM know what should be done with a
With python-updater, well, some time ago Ali Polatel implemented some
approaches to get rid of python-updater, by exporting some variable in
ebuilds that needed to be rebuilt when new python versions were
installed. I dont recall what happened with that, but we could think
of some ways to finally get rid of python-updater.
WRT python3, I too believe it is important to have it stable. Thing
is, for better or worse, upstream have it stable, and py2 and py3 are
going to co-exist for a long time. Thing is, we should really figure
out a way to have it stop messing things up. I believe with a proper
dependency handling in the eclass, we could get this to work.
As I said it already, we could start doing things simpler in the
current python.eclass and maybe that would attract some devs to help
out with it, as they find it more comfortable to work with.
Jesus Rivero (Neurogeek)