From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1QbAwo-0001S4-4p for garchives@archives.gentoo.org; Mon, 27 Jun 2011 12:29:50 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DD9D01C052; Mon, 27 Jun 2011 12:29:33 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id E9D8B1C03B for ; Mon, 27 Jun 2011 12:28:56 +0000 (UTC) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.216.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: djc) by smtp.gentoo.org (Postfix) with ESMTPSA id 562EC1BC017 for ; Mon, 27 Jun 2011 12:28:56 +0000 (UTC) Received: by qyk9 with SMTP id 9so2636525qyk.19 for ; Mon, 27 Jun 2011 05:28:54 -0700 (PDT) Received: by 10.224.137.198 with SMTP id x6mr3973745qat.45.1309177734199; Mon, 27 Jun 2011 05:28:54 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Received: by 10.229.89.67 with HTTP; Mon, 27 Jun 2011 05:28:34 -0700 (PDT) From: Dirkjan Ochtman Date: Mon, 27 Jun 2011 14:28:34 +0200 Message-ID: Subject: [gentoo-dev] The Python problem To: Gentoo Development Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: X-Archives-Hash: 2cac6a1a12040b361b95ecb05de0ac9f Hi guys, I guess by now pretty much everyone knows that the python eclass is rather complex, and that this poses some problems. This has also been an important cause for the disagreements between Arfrever and some of the other developers. Since it appears that Arfrever won't be committing much code to gentoo-x86 in the near future, I'm trying to figure out where we should go with the python.eclass. This email is an attempt at figuring that out, plus eliciting ideas to come up with a general framework that will also solve this for ruby and other similar runtimes (while supporting some of the features that the current python eclass has, but that ruby-ng doesn't have). 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? Cheers, Dirkjan