[GRASS-dev] Re: [GRASS-user] Using g.extension on Ubuntu 11.04

[Michael Barton]

Unfortunately, Hamish is correct about the issues. 

We need a standard, probably platform specific, place to put extensions where they can be automatically executed on the GRASS command line or in the extension starting wrapper. 

This involves both identifying a place to put extensions and making sure that GRASS recognizes that place as a valid path for running extensions. William is right that these are different functions. However, they should probably be related in that GRASS should by default put extensions in a place where they can be run by default. 

There should be a GEXTPATH variable, as William and Markus suggested that can specify a user-specific or system-wide location for extension installation. This should probably be set at runtime for each system. Then $GEXTPATH/bin and $GEXTPATH/scripts should be added by default to GRASS_ADDON_PATH. The user can add additional paths to the latter if desired. In g.extension, the user could set an alternative location for extension installation, but it would be up to her/him to make sure that GRASS can path to that location.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity 
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 	480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax:          480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu




On Jul 25, 2011, at 7:17 PM, <grass-user-request at lists.osgeo.org> <grass-user-request at lists.osgeo.org> wrote:

> Date: Mon, 25 Jul 2011 16:25:55 -0700 (PDT)
> From: Hamish <hamish_b at yahoo.com>
> Subject: Re: [GRASS-user] Using g.extension on Ubuntu 11.04
> To: Markus Neteler <neteler at osgeo.org>
> Cc: grass-user at lists.osgeo.org, Glynn Clements
>        <glynn at gclements.plus.com>
> Message-ID:
>        <1311636355.23061.YahooMailClassic at web110012.mail.gq1.yahoo.com>
> Content-Type: text/plain; charset=us-ascii
> 
>>> Glynn wrote:
>>>> Modify the g.extension script to use sudo rather than "su -c ...".
> Hamish:
>>> I've already done that. Try the -u flag.
> Markus:
>> I have drastically simplified g.extension to two lines, being
>> a wrapper for the way better g.extension.py which is included
>> in the wxGUI of 6.4 and 6.5.
> 
> is it way better? How? Why?
> 
> I really doubt it because the main problems with g.extension have
> nothing to do with the programming language or programmer's ability,
> and are common to both.
> 
> 
> the main structural problems with it are:
> 
> - ill/dual-defined use of GRASS_ADDON_PATH as both a /usr/local/bin
> substitute and a /usr/local prefix. William has also implemented a
> partial solution to that on OSX some time ago.
> 
> - different systems will have different ways of authorizing administration
> permissions. on linux there is su and sudo in the wild, on OSX there is
> sudo and a $USER's personal Library, on MS Windows there are other
> layers... getting this right on all permutations and combinations will
> take time.
> 
> - to install system wide or per-user?
> 
> - gcc/Makefile linking issues for C programs
> 
> - ... probably more but I'm in a rush right now (back in the office
> next week)
> 
> 
>> Find it attached. In my opinion there is not much point to
>> continue to hack the shell version if the Python script
>> does it much better. Of course you need Python being installed.
> 
> I need to research the python version more, but I don't understand how
> it could magically solve the above problems, or what is fundamentally
> broken the the existing shell version. I never really understood the
> rationale for backporting the python version of it in the first place,
> but I trust Martin to sculpt the wxGUI as he sees fit so don't mind it
> there, even if keeping two live copies of the same thing in the same
> release is inefficient to support.
> 
> most of g.ext is moving files around and running shell programs, which
> is a natural thing to keep in a shell script.
> 
> 
>> I didn't submit it yet to SVN.
> 
> Before we blast away any existing code, I'd like to know if there are
> programming or structural problems in the shell version, if the python
> version really solves these problems in a fundamentally better way, and
> why the shell version can't use the same method. I am willing to put up
> my time to fix the shell scripts if need be, but right now I'm not aware
> of any problems which are not structural in nature, ie independent of
> implementation language.
> 
> 
> I would like to post a more constructive email, but I'm being pulled out
> the door right now, and don't know of specific code problems that need
> work so can't give a patch to fix it.
> 
> 
> thanks for your patience,
> Hamish
>