1 |
On Mon, Jun 27, 2011 at 7:58 AM, Dirkjan Ochtman <djc@g.o> wrote: |
2 |
> Hi guys, |
3 |
[...] |
4 |
> So I know a bunch of people have already looked at it, and I'd like to |
5 |
> know: what do you find better about the Ruby approach compared to the |
6 |
> Python approach? Is it just the size of python.eclass, or are there a |
7 |
> number of other issues? |
8 |
> |
9 |
> Cheers, |
10 |
> |
11 |
> Dirkjan |
12 |
> |
13 |
> |
14 |
|
15 |
Let´s start by agreeing with the complexity of the Python eclass. And |
16 |
a heavy change right now, is going to be painful to say the least |
17 |
because a great deal of packages have been adapted to work the way the |
18 |
eclass works right now. |
19 |
|
20 |
I agree with Grobian in what he said about the coding style of the |
21 |
python.eclass, and would love to see that "fixed". I also agree with |
22 |
the redundancy of some variables and I think just using PYTHON_DEPEND |
23 |
should be sufficient to let the PM know what should be done with a |
24 |
specific package. |
25 |
|
26 |
With python-updater, well, some time ago Ali Polatel implemented some |
27 |
approaches to get rid of python-updater, by exporting some variable in |
28 |
ebuilds that needed to be rebuilt when new python versions were |
29 |
installed. I dont recall what happened with that, but we could think |
30 |
of some ways to finally get rid of python-updater. |
31 |
|
32 |
WRT python3, I too believe it is important to have it stable. Thing |
33 |
is, for better or worse, upstream have it stable, and py2 and py3 are |
34 |
going to co-exist for a long time. Thing is, we should really figure |
35 |
out a way to have it stop messing things up. I believe with a proper |
36 |
dependency handling in the eclass, we could get this to work. |
37 |
|
38 |
As I said it already, we could start doing things simpler in the |
39 |
current python.eclass and maybe that would attract some devs to help |
40 |
out with it, as they find it more comfortable to work with. |
41 |
|
42 |
Best regards, |
43 |
|
44 |
-- |
45 |
Jesus Rivero (Neurogeek) |
46 |
Gentoo Developer |