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 <[email protected]> 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 > [email protected] > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev >
_______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
