[GRASS-dev] GEM Wizard question

[Michael Barton]

On 5/22/07 12:01 AM, "Benjamin Ducke" <benjamin.ducke at ufg.uni-kiel.de>
wrote:

> Actually, it's not much of a problem to introduce a new default and/or
> optional install prefix in GEM. The real trouble lies in two different
> areas, as far as I can think of right now:
> 
> 1. The HTML man pages for the newly installed modules should be
> integrated into main HTML index. Currently, GEM manipulates the main
> HTML index in the install dir to do so. Of course, this requires
> superuser rights. The ideal solution would be to have a placeholder in
> the global HTML frontpage that will point to a subindex page present in
> the user's local extension directory. No idea how to do that in HTML
> 
> 2. Many people like to have new GUI menu entries in gis.m when they
> install additional modules. This means that gis.m has to be prepared to
> look for additional menu entries in the current user's extension
> directory. This should not be too hard to do.
> 
> In principle, I agree that it would be much better to have locally
> installed extension. This could simplify the logics behing GEM a lot,
> too. It would also be possible to keep both the global and local
> installation schemes side-by-side, as a system-wide extension management
> would probably also have its merits.
> 
> Benjamin

Why not try to solve these issues one at a time. Having a simple way to
create, install, and manage extensions would be a real plus and could
stimulate use of the GEM system. IMHO, we should focus on getting this right
and worry about the help files and menus a bit later.

To make life easier, why not simply keep the html help files with the
extensions and have all extensions, by default, look for help files in the
default extensions directory? Also, people can manually look at help files
if they are in an easily accessible directory. A bit of an inconvenience,
but users will be installing extensions of their choice and will have some
idea of what they want.

I'm a big fan of GUI's and having commands listed on a menu so you don't
have to remember them. BUT, getting extensions listed on the existing GUI
menu system is a pain. To get the rest of the system in general operation,
maybe just skip this. Since any extension will be installed by a user, who
presumably will know what she/he installed, calling one or two from the
command line won't be that much of a burden.

We can then think about better ways to get extensions into the menu. The
menu system is being rethought anyway with the switch to wxPython, so we
could design it with the possibility of extensions in mind if they become
widely used and the details of how and where to install them get ironed out.
For example, the menu could simply have an empty place holder for
extensions. A menu-building function could then scan the default extensions
directory to see if a menu file exists and use it to fill in the
place-holder.

Michael
> 
> William Kyngesburye wrote:
>> I've been meaning to ask about this root/external mod issue - is there
>> any plan to support installation of GEM modules in a user dir?  More
>> than just a problem of HOW to run this as root in the GUI, it's also a
>> bit of a security problem and a platform standardization issue.
>> 
>> On OSX, installing extras into an application binary is not the way
>> things are done.  They should be installed in a standard
>> plugin/extension location for the application - /Library so it is
>> globally available to users, or ~/Library to make it available only for
>> a single user.
>> 
>> These locations act as extra GIS_BASEs, in effect - they have bin, lib,
>> etc, doc... subfolders.  By use of standard GRASS env vars, they are
>> easily included into the GRASS environment, and I recently added similar
>> env vars and functions to locate external etc/ support files for modules
>> that need it.
>> 
>> For the OSX application build I've set
>> [~]/Library/GRASS/$version/Modules as the global/user locations.  For
>> now I have a separate module build template, much like GEM, but built
>> modules must then be manually copied to one of these locations, since
>> I'm too lazy to figure out alternate install targets in the makefiles.
>> 
>> It would be nice to have GEM able to install in these locations at
>> least, if not also arbitrary locations.  We would need to figure out
>> good standard locations for other platforms also.
>> 
>> 
>> On May 21, 2007, at 5:53 AM, Maris Nartiss wrote:
>> 
>>> Hi,
>>> 
>>> I'm not following GEM development and thus have two silly questions:
>>> 1) isn't possible to install additional modules via GEM into user's
>>> home directory (as option)? Thus it could be made as easy as
>>> installing some addons to Firefox.
>>> 2) if getting superuser support for GUI right is lot of work, could
>>> some GUI wizard just generate some commandline expression that could
>>> be just pasted into terminal by user as last step to run it via su or
>>> sudo?
>>> 
>>> Just my 0.02.
>>> Maris.
>>> 
>>> 
>>> 2007/5/21, Benjamin Ducke <benjamin.ducke at ufg.uni-kiel.de>:
>>>> I guess it wouldn't be too much trouble. GEM already has all that's
>>>> needed for this: zipped extension packages can be downloaded (using
>>>> wget), unzipped (to system's temp dir) and installed automatically.
>>>> There is just one catch: since all files are installed into system-wide
>>>> locations, the wizard will probably need superuser rights. So a tcl/tk
>>>> based install wizard needs to provide a way to get the superuser
>>>> password and run system commands with elevated rights.
>> 
>> -----
>> William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
>> http://www.kyngchaos.com/
>> 
>> "History is an illusion caused by the passage of time, and time is an
>> illusion caused by the passage of history."
>> 
>> - Hitchhiker's Guide to the Galaxy
>> 
>> 
>> 
>> 

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton