[pymvpa] MacPorts and pymvpa

[James Kyle]

>> First, a thanks to the developers for all the work on what promises  
>> to
>> be a very fun python library.
> have you tried it? is it fun? ;)
Only a bit, the fun is going to come from scripting in something other  
than matlab. :D


>> I took on the task of creating a MacPorts Portfile for pymvpa. Here's
> cool! Michael has prepped the install for MacOS X but I guess portfile
> should be more native, thus easier to install for mac users.
It provides a nice level of package management and eliminates the need  
to track down some of the optional dependencies.



>> -) removed references to svm_set_verbosity as this function was not  
>> in
>> the 2.88 version of libsvm
> hm... indeed - we relied too much on the patched (with those
> svm_set_verbosity exposed in Python) Debian shipped version, which
> we also provided under 3rd/libsvm and which should be built/installed
> whenever you build/install pymvpa (using Makefile though).
>
>
> Is there 'original' port of libsvm which should be preferable over
> the patched one we ship?
There's a libsvm package already in macports. The recommended way to  
build packages is against libraries installed by the ports system. So  
I was faced with patching the libsvm source or the pymvpa source. I  
went with pymvpa for expediencies sake since pushing a patch upstream  
to the libsvm maintainer would have taken a while to be approved.

> And where does it actually fail? set_verbosity is available in API  
> since
> 2.84, so if you use our svmc.i while building -- everything should be
> smooth, or am I missing something?

It's missing from the 2.88 source found here: http://www.csie.ntu.edu.tw/~cjlin/libsvm/

It fails during the build_ext of the libsvm wrapper module with:
error: ‘svm_set_verbosity’ was not declared in this scope

> For now I just added additional check in externals if actually used  
> svmc
> (committed and pushed) has that function available, but since we are
> building custom swig interface, I guess, there is no much use for
> it...
>
>> -) Added mvpa.support to the setup.py module install list, it was
>> missing and the first tutorial threw an error.
> my bad -- I was the one who refactor to have mvpa.support but  
> forgotten
> to add it to setup.py
>
> Fixed in my branch (yoh/master) and  maint/0.4
>
>> The port has the following variants (optional support):
>
>> -) pynifti
>> -) scipy
>> -) hcluster
>> -) libsvm
>
> There is no yet
> shogun
* Added: I had to make the shogun port first ;)
>
> pywt
* Added: Had to submit a pywavelet  port
>
> matplotlib/pylab
* Added matplotlib

>
>
> available in ports?
>
>> As always, if any of the developers object to my submission I will
>> remove it quickly.
>
> hm... why we should? ;) is it still released under expat (MIT)
> license?  ;-) are copyright holders statements preserved? then license
> is not violated and we only would vote 'go ahead'! We would also  
> prefer
> if you somehow point to the available sources of the project (if those
> aren't natively provided with the port, pardon my ignorance on this
> subject)

The pymvpa site is noted in the info and description parts of the port.
>
>
>> The port isn't live yet (usually takes a day or
>> so), but if anyone can't wait I'll gladly email the ports for use  
>> in a
>> local overlay.
> After it is available, it would be great if you sent us a patch  
> against
> doc/installation.txt where you would describe availability of
> portfiles... or just sent a statement describing it so we could add
> it into documentation.
>
> If you feel that you might provide numerous patches/improvements --
> don't hesitate to ask, and we will set you up with 'commit' rights, or
> in git terms it better be, rights to push, since you are allowed to
> commit locally whenever you like ;)
> keep in touch


Will do.

I have one question, currently I'm pulling the source from the master  
branch. I assume this branch is fairly volatile. Above you mention  
"maint/0.4" branch. Would the "main/\d.\d" branches be maintenance  
branches? It's best to pull from versioned/point release branches or  
tags if possible.

==One last thing....promise :) ===
Whne runing through the tutorials to test my installation, I ran into  
an error in the Getting Started Tutorial. Specifically, when creating  
a NiftiDataset the examples pass the nifti extension which produces an  
error. Cross referencing with pynifti API, I discovered that the  
extension should be left off, e.g.:

> dataset = NiftiDataset(samples='data/bold', labels=attr.labels,  
> chunks=attr.chunks, mask='data/mask')

Cheers,


-james