From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 6E6E5139694 for ; Mon, 10 Apr 2017 18:57:23 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C63E7E0DC6; Mon, 10 Apr 2017 18:57:15 +0000 (UTC) Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 85E3CE0DB8 for ; Mon, 10 Apr 2017 18:57:15 +0000 (UTC) Received: from [192.168.2.10] (85.253.85.240.cable.starman.ee [85.253.85.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: leio) by smtp.gentoo.org (Postfix) with ESMTPSA id 3CF1A33D3C7 for ; Mon, 10 Apr 2017 18:57:14 +0000 (UTC) Message-ID: <1491850630.3444.2.camel@gentoo.org> Subject: Re: [gentoo-dev] Reverse use of Python/Ruby versions From: Mart Raudsepp To: gentoo-dev@lists.gentoo.org Date: Mon, 10 Apr 2017 21:57:10 +0300 In-Reply-To: References: <8F38F35E-A4CE-4530-880C-E409E672F253@gentoo.org> <1491844472.1661.1.camel@gentoo.org> <1491847844.1661.10.camel@gentoo.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 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 Content-Transfer-Encoding: 8bit X-Archives-Salt: ea985675-8443-4362-aba4-166356bbcc62 X-Archives-Hash: 4455b3e2662f582bf5e33857418c16bb Ühel kenal päeval, E, 10.04.2017 kell 14:44, kirjutas William L. Thomson Jr.: > Again go modify a few hundred python packages to remove say 3.4. I > think about 10-20 ebuilds in. You will be scripting and looking for > another way.... No, for that you simple remove python3_4 from _PYTHON_ALL_IMPLS in python-utils-r1.eclass and call it a day. Some other day you might make a mass commit to remove 3_4 from PYTHON_COMPAT of all in-tree ebuilds, but that's just janitorial and no other effect. The current implementation makes perfect sense to me, and follows one of the zens of python: Explicit is better than implicit. Declare explicitly what version is supported, don't implicitly do so and merely hope there are no issues. If some lower level module doesn't work with new python and your higher level module wants to use the new python, repoman will catch it for you due to it having been explicit via PYTHON_USE_DEP. There is no difference with reverse approach if one would mass commit the new COMPAT into all ebuilds upon the introduction of a new python slot, but this is not done, because things would break. Mart