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

[Mike Gilbert <floppym@gentoo.org>]

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 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.

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".

As far as implementation, you would probably need to write the patches for this.

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.