[56254] trunk/dports/python

[James Kyle]

I think I can clarify this shortly.

There is no actual compile time linking done. When the variant  
packages are installed, the pymvpa port can use them by the mere fact  
that the module is present in python's path.

You could safely remove any or all of the packages and pymvpa would  
gracfully fall back on default behavior.

-james
On Aug 25, 2009, at 6:42 PM, James Kyle wrote:

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