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...

[Kubilay Kocak]

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?

I like the idea of USE_FOO=bar[:baz]<,qux> being the canonical
convention for easy transfer of existing knowledge for maintainers (perl
-> python -> *)

Koobs