[56254] trunk/dports/python

[Blair Zajac]

James Kyle wrote:
> 
> On Aug 25, 2009, at 3:33 PM, Ryan Schmidt wrote:
> 
>> On Aug 25, 2009, at 17:08, James Kyle wrote:
>>
>>>> Default variants are difficult for the user to turn off. If you want 
>>>> these features enabled by default, why not delete the variants and 
>>>> just make the port always build them?
>>>>
>>>> If there really is value in allowing the user to disable these 
>>>> features, make them "no_" variants, e.g. "no_pywavelet", 
>>>> "no_libsvm", etc.
>>>
>>> Sounds good.
>>>
>>>
>>>> Variants must do more than just add a dependency. They must also 
>>>> inform the software it is ok to use that dependency -- like you did 
>>>> in this variant:
>>>
>>> the package will use the above libraries if they are present, but not 
>>> if they are not. the variant allows the user to pull them into the 
>>> build process and so enable support. So the informing is effectively 
>>> done automatically as long as the library is installed.
>>
>> This means the port would use those libraries even if the 
>> corresponding variant was not selected. This is not ok. The port must 
>> tell the software it is not ok to use those libraries unless the 
>> variant is selected.
> 
> This is  not how the software works. I would have to rewrite it. The 
> rewrite would also break it's feature set.
> 
> It's a python module. Basically when you call a method 'foo' that, say, 
> performs a matrix convolution. If a c module exists for that method it 
> will use that. If it does not, it does the calculation using its own 
> pure python algorithm (usually much slower).

You should have a way to disable the build from picking up that software if it's 
not requested then.

> This isn't a bad thing. And I'm not sure how realistic it is to want it 
> to not do this.

It is a bad thing.  The problem is if you port uninstall one of the dependencies 
you picked up during the build, then MacPorts doesn't know about it.

Blair