[pymvpa] MacPorts and pymvpa

[Yaroslav Halchenko]

>>> 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.
Sounds like similar experience to Debian GNU/Linux package management
;-)


>> 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.
libsvm upstream is know to be salient toward proposed patches :-/
Is there a way to patch the port source of libsvm?
Are you the one who takes care about that port?

patch can be obtained from
http://patch-tracking.debian.net/patch/misc/dl/libsvm/2.85.0-1/svm.cpp
I think

patch for swig interface in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=439112

>> 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/
my bad, sorry. I thought (why?) that it was already accepted upstream,
but it seems to still be a "Debian-only feature".

> It fails during the build_ext of the libsvm wrapper module with:
> error: ‘svm_set_verbosity’ was not declared in this scope
sorry once again for giving you hope without a good reason ;-)

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


>> 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.
sorry to be anal, but does port explicitly mentions license under which
it is distributed? or contains the COPYING file within?


> 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.
so -- master is rolling 'testing' pretty much, which gets merged into
from {yoh,mh}/master whenever we feel that current state is "stable"
enough.

maint/*.* branches are more of collections hand-picked some bug fixes
and improvements (documentation) from master branches, so they must be
(theoretically) more stable than master, more up-to-date than released
version, but they slowly accumulate the lag from the master
branches

So, your decision on what to ship in the port should depend on
what you really want to provide users with.

I guess maint/ branches should be better choice to avoid havoc of bug
reports. But then you would need to switch "manually" from one to
the next one after each 'minor' release (0.3, 0.4, 0.5):
git branch -r | grep origin/maint | sort -n -r | head -1

Another solution would be simply to stick to the most recent release...

git tag | grep upstream | sort -n -r | head -1

or released tarball

In any of those cases where you base you port on git snapshot, I would
appreciate if you mention somewhere what actual git ID was used
(sha sum), so it would make it possible to track what actual state of
pymvpa was used (basing your port on tarballs make it easier in this
case).

> ==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')
wow -- that is an interesting effect... I guess burried in pynifti port
-- what version is there? I bet Michael would have better clue ;-)

to expedite it -- could you post the actual error you've received??

-- 
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student  Ph.D. @ CS Dept. NJIT
Office: (973) 353-1412 | FWD: 82823 | Fax: (973) 353-1171
        101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW:     http://www.linkedin.com/in/yarik