[56254] trunk/dports/python

[James Kyle]

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

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