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 913C6138206 for ; Tue, 16 Jan 2018 00:40:48 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id F24B2E0930; Tue, 16 Jan 2018 00:40:42 +0000 (UTC) Received: from mail-vk0-x244.google.com (mail-vk0-x244.google.com [IPv6:2607:f8b0:400c:c05::244]) (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 9CAE6E0909 for ; Tue, 16 Jan 2018 00:40:42 +0000 (UTC) Received: by mail-vk0-x244.google.com with SMTP id g83so8444282vki.4 for ; Mon, 15 Jan 2018 16:40:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scriptkitty-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=vmL+szGbKSalXqVDz1HrFsFwReWogJZApeJF2fQ5Nis=; b=GBIiKI6Zc89zzLIhNcpkDreMJtFifwHlueEvJFrM4iiS8LFgSGjhGS5uFAYdZw+1Gp BG3f+jWlo7Py9M4RoTO98Lk7frD7EjLBo3IX3t00aqnqnM+UO8O17QQ+TC/BeTo+yCAX 4wdYhFMdGlZAAz33Dpx2ubY0XqCnxyHDK0j9VSFZjUDbc1IeVTFKm5osw3OCcsokzHK3 4ALS6VJZAmZ46vX+UiaiI8HdKXnM1W3QKfP3ODl0EB+IHhK/N3cMlCOiJIN+mxsRs8wp aLyUUwVxxc5+okwmfGYFhi5PXY11dRYnMNgkfVuA4r/pmMFg8dUtSY2LPmL5fFJ35jiz TGjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=vmL+szGbKSalXqVDz1HrFsFwReWogJZApeJF2fQ5Nis=; b=AWKBx5KGe67PSkDFnd+oajsNW6bQSYSbSy/KNZAyVq+Va4qSVfKcNcW0bX8Ulrgn75 fnR2/ycsf9LAuQKgiE5dunwk5W7XxJs7qVYsy/7vvIwrtrVu8lcfXfjlz1nflYfBPc9i OhY/FC5rsHJCZ8f8Cqhp+Itix7gXGlmcABCKdjx+gpccNFvsPwiLAESF8KwTWQ8UWPnu Yiep3xqSe7Sb5QLB4LVBGCoCHuECul7EiulvceZoDFVoadOtEnbSjRKisnzVqXpXB+3P pGDtmTPrBCOLmzFHeVTnJzXMve6w42IeSi8EMY9Io8stiaujPAQQ+LXlje3z907KDPUs KqNg== X-Gm-Message-State: AKwxytdNHnoenDmfzyeYTUmQr606l/Hf30X6/UA7pwPAL+w1HfRWSqK9 IMS8l+YvIg+Gnzjv61jGijr+kB+EbYJNkykwu0flZA== X-Google-Smtp-Source: ACJfBovrPHXTd1GkYxolg/6vvjXo8YmnZ+moW7ZTGZo5MMdu1JyWaSI5xJo6xzVkyx/XAyxwqxU2DRYI6Zh+Jhqod9A= X-Received: by 10.31.207.70 with SMTP id f67mr30376516vkg.154.1516063241317; Mon, 15 Jan 2018 16:40:41 -0800 (PST) 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 Sender: antarus@scriptkitty.com Received: by 10.176.29.20 with HTTP; Mon, 15 Jan 2018 16:40:40 -0800 (PST) X-Originating-IP: [98.116.189.160] In-Reply-To: References: From: Alec Warner Date: Mon, 15 Jan 2018 19:40:40 -0500 X-Google-Sender-Auth: 97nPUnRuBQ-EOvNFBkISBTZbPis Message-ID: Subject: Re: [gentoo-dev] RFC: ${PYTHON_COMPAT_ADD} in addition to ${PYTHON_COMPAT_OVERRIDE} To: Gentoo Dev Cc: Mike Gilbert Content-Type: multipart/alternative; boundary="001a114e34d4f4c3e50562d9fa4d" X-Archives-Salt: 759e5d75-19b1-474f-b649-fb1b9c680313 X-Archives-Hash: 55e27417b3385651acd3e6f75151ae54 --001a114e34d4f4c3e50562d9fa4d Content-Type: text/plain; charset="UTF-8" On Mon, Jan 15, 2018 at 7:05 PM, Francesco Riosa wrote: > > > On 15/01/2018 18:07, Mike Gilbert wrote: > > On Mon, Jan 15, 2018 at 10:27 AM, Francesco Riosa > wrote: > >> 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 scary) > >> > >> 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 in > >> the PYTHON* arrays, example: > >> > >> -PYTHON_COMPAT=( python3_{4,5} ) > >> +PYTHON_COMPAT=( python3_{4,5} ${PYTHON_COMPAT_ADD} ) > >> > >> if someone want to bet that packages are ok with 3.6/latest (even before > >> a developer tested it) then add PYTHON_COMPAT_ADD=python3_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. > I'm seeing less value in this being a 'cache-breaking' exercise and more value in it simply being a custom eclass. If you hoist the eclass into an overlay and modify it (e.g. to set the var and get the deps you want) the caching all works out fine. 1. The source of the data is the hoisted eclass. 2. The eclass mtime changed. 3. package managers can see that and update cache metadata for inheriting ebuilds. 4. Bonus, once the cache is generated we have a valid means to see if the cache remains valid. 5. Double bonus, any ebuilds not inheriting the eclass are unaffected. I'm not sure why this is so onerous. -A --001a114e34d4f4c3e50562d9fa4d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jan 15, 2018 at 7:05 PM, Francesco Riosa <= vivo75@gmail.com&= gt; wrote:


On 15/01/2018 18:07, Mike Gilbert wrote:
> On Mon, Jan 15, 2018 at 10:27 AM, Francesco Riosa <vivo75@gmail.com> wrote:
>> In late 2015 ${PYTHON_COMPAT_OVERRIDE} has been standardized and a= dded
>> to all python eclasses, it's useful for developers that want t= est 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
>>=C2=A0 =C2=A0no python 3.5
>> - don't want to mess dependencies (the warnings in the eclass = are scary)
>>
>> So, what can be done to let the user choose it's preferred pyt= hon
>> version(s) without having to build it's own overlay?
>>
>> One solution is to change ebuilds in tree to include a user variab= le in
>> 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 = before
>> 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 o= ut,
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 metadat= a
> 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 (ben= eficial
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 exten= ded
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.

I'm seeing less value in thi= s being a 'cache-breaking' exercise and more value in it simply bei= ng a custom eclass.

If you hoist the eclass into a= n overlay and modify it (e.g. to set the var and get the deps you want) the= caching
all works out fine.

1. The sour= ce of the data is the hoisted eclass.
2. The eclass mtime changed= .
3. package managers can see that and update cache metadata for = inheriting ebuilds.
4. Bonus, once the cache is generated we have= a valid means to see if the cache remains valid.
5. Double bonus= , any ebuilds not inheriting the eclass are unaffected.

I'm not sure why this is so onerous.

-A<= /div>
=C2=A0

--001a114e34d4f4c3e50562d9fa4d--