svn commit: r364518 - in head: accessibility/py-papi audio/py-al devel/py-astroid devel/py-dynrules devel/py-game devel/py-logilab-common devel/py-ocempgui devel/py-ply devel/py-sdl2 devel/pychecke...

[Marcus von Appen]

Kubilay Kocak <koobs at freebsd.org>:

> On 11/08/2014 4:55 PM, Marcus von Appen wrote:
>> On, Mon Aug 11, 2014, Kubilay Kocak wrote:
>>
>>> On 11/08/2014 2:40 AM, Adam Weinberger wrote:
>>>> On 10 Aug, 2014, at 11:56, Marcus von Appen <mva at FreeBSD.org> wrote:
>>>>
>>>>> On, Sun Aug 10, 2014, Max Brazhnikov wrote:
>>>>>
>>>>>> On Sun, 10 Aug 2014 09:55:16 +0000 Alexey Dokuchaev wrote:
>>>>>>> On Sun, Aug 10, 2014 at 08:55:08AM +0000, Marcus von Appen wrote:
>>>>>>>> New Revision: 364518
>>>>>>>> URL: http://svnweb.freebsd.org/changeset/ports/364518
>>>>>>>> QAT: https://qat.redports.org/buildarchive/r364518/
>>>>>>>>
>>>>>>>> -USES=		pkgconfig
>>>>>>>> +USES=		pkgconfig python:2
>>>>>>>> USE_GNOME=	atk
>>>>>>>> -USE_PYTHON=	2
>>>>>>>> -USE_PYDISTUTILS=yes
>>>>>>>> -PYDISTUTILS_AUTOPLIST=	yes
>>>>>>>> +PYTHON_FEATURES=autoplist distutils
>>>>>>>
>>>>>>> Yuck, this PYTHON_FEATURES knob is ugly.  Why not follow Perl's example
>>>>>>> instead (USES=perl and USE_PERL)?  It both makes more sense  
>>>>>>> and shorter.
>>>>>>
>>>>>> ugly or not, it's a matter of taste. But PYTHON_FEATURES usage  
>>>>>> is inconsistent
>>>>>> with COMPILER_FEATURES (read only var). Could we rename it  
>>>>>> while it's not too late?
>>>>>
>>>>> Using USE_PYTHON is a problem, since this would be inconsistent with many
>>>>> other parts of the infrastructure. Aside from that, it would  
>>>>> need a lot of
>>>>> glue code for the transition phase.
>>>>>
>>>>> Regardless of that, if portmgr's common suggestion is that  
>>>>> XXX_FEATURES is
>>>>> about testing for a certain feature (read-only), I'm fine with  
>>>>> it and open for
>>>>> suggestions, which describe that infrastructure bit X wants to enable a
>>>>> certain infrastructure feature.
>>>>>
>>>>> PYTHON_FEATURES is in my opinion the best by far. If the  
>>>>> consensus is to use
>>>>> USE_PYTHON, similar to USE_PERL5, this will require us to  
>>>>> migrate all python
>>>>> ports from USE_PYTHON to USES=python first and will take some time.
>>>>
>>>> Can it just treat USE_PTYHON as PYTHON_FEATURES if USES=python is defined?
>>>
>>> Marcus, how feasible is this (minus the typo) to make the transition
>>> without a mass conversion first-phase?
>>
>> It won't work with the proposed way. It'd be possible to create a  
>> check based
>> what USE_PYTHON contains, thought, but I doubt that check to be completely
>> bullet-proof, so a conversion to USES=python should be done as fast as
>> possible.
>
> Hmm :| *ponders*
>
>>> I like the idea of USE_FOO=bar[:baz]<,qux> being the canonical
>>> convention for easy transfer of existing knowledge for maintainers (perl
>>> -> python -> *)
>>
>> I brought this to portmgr's attention, so we do not run into this  
>> again, when
>> other parts are converted to USES. As soon as portmgr made a clear  
>> statement,
>> we can start with whatever should be used.
>
> Awesome :)
>
> Should we quieten the deprecation warnings until we have clarity for
> moving forward?

At least the PYTHON_FEATURES notes should be silenced for now. The back-end
implementation in python.mk can stay as is, since this won't have an impact.
The USE_PYTHON -> USES=python warning can be kept, too.

Cheers
Marcus