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-requ...@lists.osgeo.org> <grass-user-requ...@lists.osgeo.org> wrote: > Date: Mon, 25 Jul 2011 16:25:55 -0700 (PDT) > From: Hamish <hamis...@yahoo.com> > Subject: Re: [GRASS-user] Using g.extension on Ubuntu 11.04 > To: Markus Neteler <nete...@osgeo.org> > Cc: grass-u...@lists.osgeo.org, Glynn Clements > <gl...@gclements.plus.com> > Message-ID: > <1311636355.23061.yahoomailclas...@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 > _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
