1 |
On Mon, Jun 27, 2011 at 15:08, Fabian Groffen <grobian@g.o> wrote: |
2 |
> On 27-06-2011 14:28:34 +0200, Dirkjan Ochtman wrote: |
3 |
>> So I know a bunch of people have already looked at it, and I'd like to |
4 |
>> know: what do you find better about the Ruby approach compared to the |
5 |
>> Python approach? Is it just the size of python.eclass, or are there a |
6 |
>> number of other issues? |
7 |
> |
8 |
> Part of the eclass problem is IMO coding style. Change it to use |
9 |
> normally-sized variable names, and to respect 80-columns width, and it |
10 |
> already becomes much more consumable. |
11 |
|
12 |
That seems like the somewhat more straightforward part. |
13 |
|
14 |
> The whole comparison of Python vs Ruby vs Java and perhaps the outlook |
15 |
> to Perl is kind of hard. What the python eclass accomplishes is very |
16 |
> neat. What probably started as a way to be able to have both python 2.x |
17 |
> and 3.x installed side by side (because the latter is not really |
18 |
> compatible with the former) got IMO out of hand by supporting any python |
19 |
> version to coexist with another. I guess many people developing with |
20 |
> Python actually love this feature, and in itself, I believe it has use |
21 |
> that cannot be ignored any more now. The way in which this feature was |
22 |
> implemented -- sometimes it more felt as pushed through the throat -- is |
23 |
> more of the rebelious kind than the smooth path for ebuild developers. |
24 |
|
25 |
Right. I think the ability to have python packages simultaneously |
26 |
installed in python2.6, python2.7 and pypy1.5, for example, is pretty |
27 |
cool to have. And going from USE to RESTRICT (Ruby vs. Python, right |
28 |
now) is probably more sensible in the Python ecosystem (i.e. where |
29 |
something that runs on 2.6 is likely to also run on 2.7). |
30 |
|
31 |
> It would be nice when a similar technique could be implemented only |
32 |
> once, in a consistent way. In a way, multilib-portage can be considered |
33 |
> equal to one of the objectives of the python (and ruby) eclass: |
34 |
> multiple times compiling and installing for different ABIs. |
35 |
|
36 |
Yeah, but it'd be nice not to have to compile subversion three times |
37 |
just because we want the python bindings installed in three different |
38 |
Python environments. |
39 |
|
40 |
> All in all, I don't fancy a rewrite from scratch, since it all works |
41 |
> at the moment, and doing so takes another large bit of work. Instead, |
42 |
> aligning the work with others to create a similar approach in ebuilds |
43 |
> (for ebuild developers) would be favourable to me. And perhaps that |
44 |
> should mean that variables which contain versions with some syntax that |
45 |
> specify ranges and more should just go, to be replaced by something |
46 |
> which is much less powerful in expressiveness, but much easier to |
47 |
> understand in the general picture, such as the USE-flags from the ruby |
48 |
> eclass. |
49 |
|
50 |
That sounds very similar to what I think would be best. |
51 |
|
52 |
Cheers, |
53 |
|
54 |
Dirkjan |