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

[Francesco Riosa]

On 16/01/2018 01:40, Alec Warner wrote:
>
>
> On Mon, Jan 15, 2018 at 7:05 PM, Francesco Riosa <vivo75@×××××.com
> <mailto:vivo75@×××××.com>> wrote:
>
>
>
>     On 15/01/2018 18:07, Mike Gilbert wrote:
>     > On Mon, Jan 15, 2018 at 10:27 AM, Francesco Riosa
>     <vivo75@×××××.com <mailto: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.
>
>
> 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
That's a good idea, in the past I've failed to completely understand how
portage inherit eclasses in overlays, but if I can figure that out
probably this could be a solution.
Also depending from the magnitude of changes the four python eclasses
need and the correlated maintenance burden.