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@lists.osgeo.org> <grass-user-request@lists.osgeo.org> wrote:
Date: Mon, 25 Jul 2011 16:25:55 -0700 (PDT)
From: Hamish <hamish_b@yahoo.com>
Subject: Re: [GRASS-user] Using g.extension on Ubuntu 11.04
To: Markus Neteler <neteler@osgeo.org>
Cc: grass-user@lists.osgeo.org, Glynn Clements
<glynn@gclements.plus.com>
Message-ID:
<1311636355.23061.YahooMailClassic@web110012.mail.gq1.yahoo.com>
Content-Type: text/plain; charset=us-asciiGlynn 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