Mac Science Collaboration group

[James Kyle]

Morning,

I'm new to the the macports dev list, but I've been actively  
maintaining a chunk of ports for about a year now and patching for  
longer (commit request pending).

I'd like to propose a new collaboration group called Mac Science that  
would, in spirit, be very similar to the Debian Science initiative.
http://wiki.debian.org/DebianScience

My incentive for this proposal is due to three observations I've made  
as mac desktop user and researcher. I also have a moderate level of  
confidence that I could enlist some level of direct apple support or  
collaboration in the project.

I welcome any and all feedback in the matter, both positive and  
negative. :)


I'll outline my incentives for the proposal below.

Issue:
"Holes" in the science library. This isn't necessarily a macports  
issue. Currently, there is no one-stop answer to a curious researcher  
on where to go for his science apps. MacPorts provides some but not by  
any means all of the usual suspects for computational work. Especially  
some of the more specialized libraries.

Solution:
A Mac Science project could specialize in these types of Port  
requests. We could host a wiki with a "provided list" and "hit list"  
of missing portfiles for developers to whittle away at including  
ticket # links and any current issues with them. The only clear  
advantage I see in this is the specialization aspect and the "one  
stop" answer to the "what does macports have for science? What does it  
need?" questions.

-------------
Issue:
Coordination between package releases and versions

When updating science oriented (math, analysis, etc) ports, I've often  
noticed a cascade effect where several other ports also require  
updating and/or patching. As these are often maintained by others,  
ensuring that everything gets updated in synchrony can be touch and go.

Solution:
A Mac Science project could have project level point releases which  
could ensure that, at any given project release, that all packages  
work well together.

---------------
Issue:
Desirability of a "one shot, up and running" collection of meta-ports.  
This is highly desirable amongst researchers. They don't just want  
numpy, they want numpy + matplotlib + scipy + pymvpa + shogun + etc  
etc. And the catch is, sometimes they don't know it. . . they just  
know they want "all that numerical stuff for python" or "all that R  
stuff for machine learning" and so on.

Solution:
This is addressed to a certain extent by variants, but meta packages  
provide a more straight shot, lower barrier to entry solution. Meta- 
packages could serve as a "best fit for most people" bundles that  
address specific areas of science. This is *highly* desirable in a lab  
environment where there are two kinds of researchers: the ones who  
"get" all this compiling, building, terminal, etc. "stuff" and those  
who often do not need or have a desire to know anything but the  
limited subset of commands they need to get their daily work done.

Cheers,

James Kyle
Center for Cognitive Neuroscience, UCLA