Re: [gentoo-python] [PATCH python-r1 2/2] Introduce PYTHON_COMPAT_OVERRIDE to make testing easier.

[Nikolaj Sjujskij]

Den 2013-03-21 15:55:23 skrev Michał Górny <mgorny@g.o>:

> On Thu, 21 Mar 2013 15:30:35 +0400
> "Nikolaj Sjujskij" <sterkrig@×××××××.com> wrote:
>
>> Den 2013-03-21 14:27:42 skrev Michał Górny <mgorny@g.o>:
>>
>> > On Thu, 21 Mar 2013 10:59:49 +0400
>> > "Nikolaj Sjujskij" <sterkrig@×××××××.com> wrote:
>> >
>> >> Den 2013-03-20 23:03:43 skrev Michał Górny <mgorny@g.o>:
>> >>
>> >> > On Wed, 20 Mar 2013 15:10:18 +0400
>> >> > "Nikolaj Sjujskij" <sterkrig@×××××××.com> wrote:
>> >> >
>> >> >> Den 2013-03-18 02:33:50 skrev Michał Górny <mgorny@g.o>:
>> >> >>
>> >> >> > 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?
It should be enabled. To be honest, I fail to see your point: in case of  
PYTHON_COMPAT_OVERRIDE='python2_7 python3_3' I see no difference in  
current code and my proposal: either way python2_7 would be enabled  
regardless of USE-flag settings, wouldn't it?

On the other hand, let's consider testing something like PyQt4 with, say,  
Python 3.4, on the system with PYTHON_TARGETS="python2_7 python3_3". In  
"my case" with PYTHON_COMPAT_OVERRIDE="python3_4" module would be built  
three times, which isn't that good. Dealing in eclass with  
PYTHON_COMPAT_OVERRIDE="-python2_7 -python3_3 python3_4" could be tricky,  
so maybe the current situation is the most convenient.