Re: [gentoo-dev] RFC: ${PYTHON_COMPAT_ADD} in addition to ${PYTHON_COMPAT_OVERRIDE}

[Francesco Riosa]

On 15/01/2018 18:07, Mike Gilbert wrote:
> On Mon, Jan 15, 2018 at 10:27 AM, Francesco Riosa <vivo75@×××××.com> 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.