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

[Alec Warner <antarus@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3617 bytes --]

On Mon, Jan 15, 2018 at 7:05 PM, Francesco Riosa <vivo75@gmail.com> wrote:

>
>
> On 15/01/2018 18:07, Mike Gilbert wrote:
> > 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.
> 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

[-- Attachment #2: Type: text/html, Size: 4646 bytes --]