From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id DF4EE13800E for ; Mon, 30 Jul 2012 16:54:45 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D9D4EE06C5; Mon, 30 Jul 2012 16:54:17 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id ACD7DE06C8 for ; Mon, 30 Jul 2012 16:54:17 +0000 (UTC) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: djc) by smtp.gentoo.org (Postfix) with ESMTPSA id E380F1B4024 for ; Mon, 30 Jul 2012 16:54:16 +0000 (UTC) Received: by wibhm2 with SMTP id hm2so1558981wib.10 for ; Mon, 30 Jul 2012 09:54:14 -0700 (PDT) Received: by 10.180.97.135 with SMTP id ea7mr43977959wib.11.1343667254450; Mon, 30 Jul 2012 09:54:14 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Discussions centering around the Python ecosystem in Gentoo Linux X-BeenThere: gentoo-python@gentoo.org X-BeenThere: gentoo-python@lists.gentoo.org MIME-Version: 1.0 Received: by 10.216.162.209 with HTTP; Mon, 30 Jul 2012 09:53:54 -0700 (PDT) In-Reply-To: References: <5015EDC2.202@gentoo.org> From: Dirkjan Ochtman Date: Mon, 30 Jul 2012 18:53:54 +0200 Message-ID: Subject: Re: [gentoo-python] Python 3 in Gentoo To: Mike Gilbert Cc: gentoo-python Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 1256dca5-4efb-44dd-9ab1-1dbee42d5285 X-Archives-Hash: c426f153337d6cc60df08c280a317bc5 On Mon, Jul 30, 2012 at 5:56 PM, Mike Gilbert wrote: > Where else in the tree could this concept be applied? I think php5 was first handled this way? Maybe apache2? dev-python/jinja2, for sure. > I would prefer to avoid going through the EAPI process if it is just > going to be used for python. And even then, I'm not really excited > about the prospect of explaining it. Nor am I, really. And may be we should pursue your idea at the same time. But I think it would sure be nice if we can prevent painting ourselves into a similar corner a few years down the road. > A solution that works within the confines of the current EAPI spec > should be greatly preferred. So do you know how many ebuilds we'd have to update to get it right? Cheers, Dirkjan