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

["Michał Górny" <mgorny@gentoo.org>]

W dniu pon, 15.01.2018 o godzinie 16∶27 +0100, użytkownik Francesco
Riosa napisał:
> 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)

Because it is not meant to be used for that purpose, and it is not meant
to be used by users at all! It's just a quick hack for developer who
wants to UNLIKELY(check if package works with implementation X) before
he starts the effort on modifying PYTHON_COMPAT in ebuilds.

> 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.
> 
> Indeed biggest problem in changing $PYTHON* variables is that metadata
> also change and cache is invalidated.
> 
> However if the problem is known (*), and if the change to metadata is
> stable per "system"/"gentoo repo clone", then the solution to the
> problem is easy; just run $(egencache --update -j$(nproc) --repo gentoo)
> after each sync.

This won't work. You are wrongly presuming that egencache regenerates
cache unconditionally. It does so only if either ebuild or eclass
content changed. So it worked for you once because you modified ebuilds
and/or eclasses. It won't work when you change PYTHON_COMPAT_ADD.

I haven't checked the Portage details but it may see the metadata change
when installing the package. Which means it would install package with
unsatisfied dependencies (because it satisfied dependencies from cache),
then store the final dependencies and TADAAM, you've got broken
depgraph.

> The most important thing is that this solution is scriptable and need no
> human intervention.

So is gpy-upgrade-impl.

> 
> Notice also that it's easy to have an array with duplicate values
> PYTHON_COMPAT=( python3_6 python3_6 ) but at a first glance
> _python_set_impls() is resilient to this.
> 
> (*) In a perfect world, where global variables that can change metadata
> are known {egencache,emerge} can be made conscious and warn if the cache
> is invalid, but that's out of scope at the moment.

This isn't perfect world. This is the exact opposite of it, it would be
a mess. Also, conscious tools would probably start plotting against you
if you'd give them such horrible tasks.

-- 
Best regards,
Michał Górny