On 16/01/2018 01:40, Alec Warner wrote: > > > On Mon, Jan 15, 2018 at 7:05 PM, Francesco Riosa > wrote: > > > > On 15/01/2018 18:07, Mike Gilbert wrote: > > On Mon, Jan 15, 2018 at 10:27 AM, Francesco Riosa > > 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.