On Mon, Jun 27, 2011 at 15:08, Fabian Groffen <grob...@gentoo.org> wrote: > On 27-06-2011 14:28:34 +0200, Dirkjan Ochtman wrote: >> 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? > > Part of the eclass problem is IMO coding style. Change it to use > normally-sized variable names, and to respect 80-columns width, and it > already becomes much more consumable.
That seems like the somewhat more straightforward part. > The whole comparison of Python vs Ruby vs Java and perhaps the outlook > to Perl is kind of hard. What the python eclass accomplishes is very > neat. What probably started as a way to be able to have both python 2.x > and 3.x installed side by side (because the latter is not really > compatible with the former) got IMO out of hand by supporting any python > version to coexist with another. I guess many people developing with > Python actually love this feature, and in itself, I believe it has use > that cannot be ignored any more now. The way in which this feature was > implemented -- sometimes it more felt as pushed through the throat -- is > more of the rebelious kind than the smooth path for ebuild developers. Right. I think the ability to have python packages simultaneously installed in python2.6, python2.7 and pypy1.5, for example, is pretty cool to have. And going from USE to RESTRICT (Ruby vs. Python, right now) is probably more sensible in the Python ecosystem (i.e. where something that runs on 2.6 is likely to also run on 2.7). > It would be nice when a similar technique could be implemented only > once, in a consistent way. In a way, multilib-portage can be considered > equal to one of the objectives of the python (and ruby) eclass: > multiple times compiling and installing for different ABIs. Yeah, but it'd be nice not to have to compile subversion three times just because we want the python bindings installed in three different Python environments. > All in all, I don't fancy a rewrite from scratch, since it all works > at the moment, and doing so takes another large bit of work. Instead, > aligning the work with others to create a similar approach in ebuilds > (for ebuild developers) would be favourable to me. And perhaps that > should mean that variables which contain versions with some syntax that > specify ranges and more should just go, to be replaced by something > which is much less powerful in expressiveness, but much easier to > understand in the general picture, such as the USE-flags from the ruby > eclass. That sounds very similar to what I think would be best. Cheers, Dirkjan
