On Thu, 21 Mar 2013 15:30:35 +0400
"Nikolaj Sjujskij" <sterkrig@myopera.com> wrote:

> Den 2013-03-21 14:27:42 skrev Michał Górny <mgorny@gentoo.org>:
> 
> > On Thu, 21 Mar 2013 10:59:49 +0400
> > "Nikolaj Sjujskij" <sterkrig@myopera.com> wrote:
> >
> >> Den 2013-03-20 23:03:43 skrev Michał Górny <mgorny@gentoo.org>:
> >>
> >> > On Wed, 20 Mar 2013 15:10:18 +0400
> >> > "Nikolaj Sjujskij" <sterkrig@myopera.com> wrote:
> >> >
> >> >> Den 2013-03-18 02:33:50 skrev Michał Górny <mgorny@gentoo.org>:
> >> >>
> >> >> > The PYTHON_COMPAT_OVERRIDE can be set in the environment to enforce
> >> >> > a different set of Python implementations than one being  
> >> intersection
> >> >> > of PYTHON_COMPAT and PYTHON_TARGETS.
> >> >> >
> >> >> > Due to technical limitations, the variable influences only the list
> >> >> > of implementations actually used. USE flags, dependencies and other
> >> >> > metadata variables are not modified.
> >> >> Push it to tree, please, I'd like to test it :)
> >> >
> >> > Pushed :).
> >>   Yup, works fine: https://bugs.gentoo.org/show_bug.cgi?id=462566
> >> One minor thing. I have PYTHON_TARGETS="python2_7 python3_3" in  
> >> make.conf,
> >> pylint ebuild has PYTHON_COMPAT=( python2_{5,6,7} python{3_1,3_2} ). I
> >> expected `PYTHON_COMPAT_OVERRIDE="python3_3" emerge -1 pylint` to  
> >> install
> >> pylint for both 2.7 and 3.3. Of course, it's "OVERRIDE", not "UPDATE",  
> >> but
> >> still.
> >>   A minor thing, really, and I won't insist on changing this behaviour.
> >> Thanks in any case :)
> >
> > I've decided to go this way since you can't change the IUSE. Therefore,
> > you can't really control the enabled implementations via USE flags. If
> > it worked like you suggested, some of the implementations would respect
> > USE flags and some other wouldn't -- that would be confusing.
> Agreed. But what about something like this:
> 
> 
> --- /usr/portage/eclass/python-r1.eclass	2013-03-20 23:31:15.000000000  
> +0400
> +++ python-r1.eclass	2013-03-21 15:17:58.000000000 +0400
> @@ -604,11 +604,11 @@
>   			ewarn
>   			ewarn "Dependencies won't be satisfied, and PYTHON_TARGETS will be  
> ignored."
>   			_PYTHON_COMPAT_OVERRIDE_WARNED=1
>   		fi
> 
> -		MULTIBUILD_VARIANTS=( ${PYTHON_COMPAT_OVERRIDE} )
> +		MULTIBUILD_VARIANTS=( ${PYTHON_COMPAT_OVERRIDE} ${PYTHON_TARGETS} )
>   		return
>   	fi
> 
>   	_python_validate_useflags
>   	_python_check_USE_PYTHON
> 
> 
> This way eclass would use PYTHON_TARGETS, but equally "disrespect" all the  
> implementations regarding USE-flags etc, wouldn't it? :)
> (Probably we'd have to deal with duplicates in that array, but that's only  
> an idea).

Think of PYTHON_COMPAT_OVERRIDE='python2_7 python3_3'. Should 2_7 be
enabled if it's both in override and real _COMPAT, and disabled via USE
flag?

-- 
Best regards,
Michał Górny