[GRASS5] GRASS extension manager proposal

Michael Barton michael.barton at asu.edu
Thu Dec 16 11:24:08 EST 2004



On 12/16/04 2:11 AM, "Radim Blazek" <blazek at itc.it> wrote:

> Roger Bivand wrote:
>>> why bother with g.install and just put it all in GRASS CVS?
>> 
>> Because, as Benjamin and others (especially Paolo Cavallini) have
>> suggested, a development model with add-in modules is vastly more robust
>> that one in which everything is in the same tarball. Central servicies
>> need to be in the core distribution, but everything else should be
>> modularised. They can be stored on a central CVS repository, but do not
>> need to be in the same project, just to follow the same installation
>> rules. 
> 
> I agree. I prefer an archive where everybody can add packages. It is not
> realistic, to create CVS account for every student who writes a script.
> 
> This is certainly good starting point:
> http://www.public.asu.edu/~cmbarton/grass_scripts.htm
> 

If this kind of repository ever catches on, we might want to think about
moving it to the Wiki server. I mentioned this to Markus and he was
favorable.

The problem with the ASU server is that all submissions currently need to be
sent to me personally (i.e., via email or my office Mac) and then put on the
ftp/html download server by me manually. I don't mind managing or helping to
manage a GRASS applications repository, but using the ASU server for this is
a pretty klunky way to do it at present. It would be better to have a
submissions area accessible via some kind of broad but controled access (the
new Wiki server seems good at this). New submissions could wait there for
testing. After testing, they could then be moved into a subdirectory
hierarchy that matched their function and place in the GUI hierarchy.


Michael
______________________________
Michael Barton, Professor of Anthropology
School of Human, Evolution and Social Change
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton




More information about the grass-dev mailing list