Mac Science Collaboration group

[Darren Weber]

Count me in.  All sounds good to me.  Not clear on the mechanics of
meta-ports (maybe they contain tcl code with exec's to call port for
installations of ports and all the variants required).  The idea of a
science milestone might work in trac (but maybe raises issues of conflicts
about whether port tickets can tag multiple milestones).

Best, Darren



On Mon, May 11, 2009 at 11:48 AM, James Kyle <jameskyle at ucla.edu> wrote:

> 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
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090511/3fdb0eca/attachment.html>