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

[Francesco Riosa]

On 16/01/2018 08:57, Michał Górny wrote:
> 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.
supposed that, but at this point I fail to see the benefit versus the
added complexity in the eclasses, however that's not my business.
>
>> 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.
ouch, that basically kill the proposal, unless portage is modified to
check known cache modifying variables, which isn't something I'd like to
create.
>
>> The most important thing is that this solution is scriptable and need no
>> human intervention.
> So is gpy-upgrade-impl.
It seem to do the job, one piece missing is something that monitor
gentoo repository to see if it has better version (still w/o wanted
python), an inotify for ebuilds. Suggestions?
>
>> 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.
>