| 1 |
On Tue, 28 Jun 2011 20:03:34 -0430 |
| 2 |
"Jesus Rivero (Neurogeek)" <neurogeek@g.o> wrote: |
| 3 |
|
| 4 |
> On Mon, Jun 27, 2011 at 7:58 AM, Dirkjan Ochtman <djc@g.o> |
| 5 |
> wrote: |
| 6 |
> > Hi guys, |
| 7 |
> [...] |
| 8 |
> > So I know a bunch of people have already looked at it, and I'd like |
| 9 |
> > to know: what do you find better about the Ruby approach compared |
| 10 |
> > to the Python approach? Is it just the size of python.eclass, or |
| 11 |
> > are there a number of other issues? |
| 12 |
> |
| 13 |
> Let´s start by agreeing with the complexity of the Python eclass. And |
| 14 |
> a heavy change right now, is going to be painful to say the least |
| 15 |
> because a great deal of packages have been adapted to work the way the |
| 16 |
> eclass works right now. |
| 17 |
> |
| 18 |
> [...] |
| 19 |
> |
| 20 |
> As I said it already, we could start doing things simpler in the |
| 21 |
> current python.eclass and maybe that would attract some devs to help |
| 22 |
> out with it, as they find it more comfortable to work with. |
| 23 |
|
| 24 |
I think it would be better to simply start from scratch with |
| 25 |
a clean python-2.eclass. Instead of adding new features and another lot |
| 26 |
of conditionals for EAPI=4, just make that code a part of new eclass. |
| 27 |
|
| 28 |
And remember, the more complex code is, the more painful it becomes for |
| 29 |
things like metadata generation. |
| 30 |
|
| 31 |
-- |
| 32 |
Best regards, |
| 33 |
Michał Górny |
Archives