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 AB8E8138206 for ; Tue, 16 Jan 2018 00:05:44 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 79BBBE08F5; Tue, 16 Jan 2018 00:05:39 +0000 (UTC) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 1779FE08D3 for ; Tue, 16 Jan 2018 00:05:39 +0000 (UTC) Received: by mail-wm0-x22d.google.com with SMTP id i11so5082873wmf.4 for ; Mon, 15 Jan 2018 16:05:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=ETP7inOtrkaqTVd14hMlPwUl69xUNfFGqNy9KqxpNJw=; b=UpI6BqjXMMc45zq+iRpbo4Sv17LNzVSEynY5LfMaalHVy64pUF7Y1XXygm3Dx2NcsY seZGwjzBS71WVu4H+swBHn6ciCCvkiKWCnOfHN4BXf2ny2G29KWxmCHeiUlWWDgGHOb0 pYeDhAEqaw17XwUAcratBaZ46bkSbImFplZ/R6No80cKuuP9WRge+Cj2DLU/a6xHzrCW dYLUR8S+jTeyH8b7OY00r4c73r/mjMji1zDTcXnqALX5SqzN4sf+p8BWfWnQUd3Czi3s YlsvjXocGO2dhQqSB9U4X0AZCzBXmuQYu4sh9rRxKyM8lKjyzxIoz4dZ+n2CO7R1dSeo sIVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=ETP7inOtrkaqTVd14hMlPwUl69xUNfFGqNy9KqxpNJw=; b=M0gFo57EGVvCRLEEmrX/Xnv2sJQjYss25OyJxCRJs7VBhW4sKV4v4LQzsuzHCn/QuS fn+lU7DedB5JljoUFTid1M5CeTB93ZF4P9KhG4svKKJ4fu3+rvotqeKSAgfqbw9l2Cyw XZQudxPuznMl2CAlrALq1HyXwCDVKJ4UtJTPyddefm6trZcm/mVlGdTWytpQnJSRGY1q wJqaaiZ6xRGhTdu1vXzN0ekoHbtz+1aRRYZBblE/oZ2+P0Qfkd0FZGF2PaVbkXSSjBxp edXKOC+piDIXPkHRinnn5aj8D5on063lD1UQHhRbuopD1J8TvzYW7slWzuSmor4bExPN cAag== X-Gm-Message-State: AKwxytdYVNh/FE69e6e0Ev1TQO4pEopHLA8dmbEKJpqs+qq+0RBR4ovY xEZL/M/p7qYaX1cGDOIewCDAvW8G X-Google-Smtp-Source: ACJfBot3o4wbcT9yrpq+Cy8nvLijJspH+s6IF8NgQ8JB91VZXySWzxuL2JbdDwW3BmLWM0Zu6Zdo7g== X-Received: by 10.28.211.67 with SMTP id k64mr11438692wmg.95.1516061137685; Mon, 15 Jan 2018 16:05:37 -0800 (PST) Received: from [192.168.1.128] (net-188-218-203-120.cust.vodafonedsl.it. [188.218.203.120]) by smtp.gmail.com with ESMTPSA id s86sm1170502wma.29.2018.01.15.16.05.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jan 2018 16:05:37 -0800 (PST) Subject: Re: [gentoo-dev] RFC: ${PYTHON_COMPAT_ADD} in addition to ${PYTHON_COMPAT_OVERRIDE} To: gentoo-dev@lists.gentoo.org, Mike Gilbert References: From: Francesco Riosa Message-ID: Date: Tue, 16 Jan 2018 01:05:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 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 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Archives-Salt: c9b4b8d3-f4ca-4bcb-8bce-e090b5d957c8 X-Archives-Hash: 6658c9449ff0e3d10b87b8211833e681 On 15/01/2018 18:07, Mike Gilbert wrote: > On Mon, Jan 15, 2018 at 10:27 AM, Francesco Riosa wr= ote: >> In late 2015 ${PYTHON_COMPAT_OVERRIDE} has been standardized and added= >> to all python eclasses, it's useful for developers that want test and >> mark the package for newer versions of python. >> >> However (unless I'm missing something) PYTHON_COMPAT_OVERRIDE is not >> usable if: >> - the user want only python 2.7 and 3.6 (latest) installed >> no python 3.5 >> - don't want to mess dependencies (the warnings in the eclass are scar= y) >> >> So, what can be done to let the user choose it's preferred python >> version(s) without having to build it's own overlay? >> >> One solution is to change ebuilds in tree to include a user variable i= n >> the PYTHON* arrays, example: >> >> -PYTHON_COMPAT=3D( python3_{4,5} ) >> +PYTHON_COMPAT=3D( python3_{4,5} ${PYTHON_COMPAT_ADD} ) >> >> if someone want to bet that packages are ok with 3.6/latest (even befo= re >> a developer tested it) then add PYTHON_COMPAT_ADD=3Dpython3_6 to >> /etc/portage/make.conf and run egencache. > I like the idea to inject values into PYTHON_COMPAT instead of > overriding it completely. I'm pretty sure this can/should be > implemented in the eclass without touching ebuilds. In my mind that was to leave ebuilds developers the ability to opt out, but well that could also be done in the eclasses. Opt out could be beneficial for packages that only support python 2.7, or where there are known and documented problems with different python versions. > > I'm not sure I really like the idea of affecting the other metadata > variables. I can see your point about wanting to remove python > versions that would otherwise satisfy dependencies. If metadata is > modified this way, it would definitely be "unsupported". I've not tought about remove python versions, only add them (beneficial for users that like to use experimental python versions) However the supported python version are translated and build important cached variables IUSE, DEPEND, etc. so there is no way to cleanly modify those variable after the cache has been generated. The only viable option is to regenerate, update or delete it. > > As far as implementation, you would probably need to write the patches = for this. If there is consensus that's not a problem, cannot guarantee to be fast however > > Also, I expect the QA team might have some objections, so you may want > to discuss it with them (especially mgorny) before spending too much > time on it. I'd like to hear mgorny opinions but that should be a more extended decision than only QA and the python eclasses developer(s). If nothing else because deciding that sometimes may be good to let the user break the cache is a global decision and documentation need to be added.