[56254] trunk/dports/python

[James Kyle]

On Aug 25, 2009, at 6:20 PM, Blair Zajac wrote:

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


I'm confused here. Why would macports not know about a port uninstall?

Let's take shogun as an example. If the shogun python library is  
available, some of the methods in pymvpa will use them. If not, it  
uses their own native code or (I think) displays an exception to the  
user if it doesn't have a built-in alternative.

The psuedo check might be:

if sg module found in path:
     use it
elsif built in exists:
     use built in
else:
     raise "functionality not enabled"

The variant simply allows the user to declare "yes I want these  
functions available, so please pull these libraries in so that pymvpa  
can load them".  There's nothing about it that slips files in or would  
remove them outside of the ports system.

By all means if there is some breakage that could occur here I am  
eager to remedy it, but I don't see it. I wanted to give users a bit  
of flexibility in choosing which libraries they wanted support for in  
the pymvpa package.

I suppose I could take an everything and the kitchen sink approach and  
just include them as dependencies and either no variants or no_*  
variants. But in practice this is really has no effect on the build  
process itself.

-james