[GRASS-dev] GRASS extensions/addons mismatch

[cmbarton]

There is another issue for Mac users--and this affects the overall permissions/settings files too.

All directories that begin with a "." are by default hidden from Mac users. Since permissions and settings can be accessed in other ways, this is not a big problem.

But if we are putting addons into the same hidden directory, it is more troublesome.

William has previously put this into the /Library folder as a visible folder. This is a much more sensible place for the Mac. So we need to treat Mac's differently from Linux, like we do Windows.

Michael
______________________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

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

On Dec 14, 2011, at 6:54 AM, grass-dev-request@lists.osgeo.org wrote:

Date: Wed, 14 Dec 2011 05:53:16 -0800 (PST)
From: Hamish <hamish_b@yahoo.com>
Subject: Re: [GRASS-dev] GRASS extensions/addons mismatch
To: GRASS developers list <grass-dev@lists.osgeo.org>, Martin Landa
       <landa.martin@gmail.com>
Message-ID:
       <1323870796.32415.YahooMailClassic@web110007.mail.gq1.yahoo.com>
Content-Type: text/plain; charset=us-ascii

Martin wrote:

currently the GRASS AddOns extensions are installed on
GNU/Linux to

$HOME/.grass<major_version>/addons

and on Windows to

$AppData\GRASS<major_version>\addons

(i.e. if you didn't already have GRASS_ADDON_PATH set to something
custom and you let the defaults make the choice for you)

This layout doesn't allow to install extensions for more
installed versions of GRASS. In other words, addons for
GRASS 6.4.2 and GRASS 6.5 are installed on the same place

fwiw most of my personal ADDON scripts are scripts not compiled,
and I most often run into this problem when switching between grass
6 and 7 when the module parameters and flags have changed.

also I see it every now and then for trying to run new flags on older
grasses which don't have that flag yet.

for (my) scripts where grass 6/7 matters I split up $GRASS_VERSION into
majors and minors and test the major version, then if/else to have the
right thing happen automatically. (e.g. change the way I call d.mon)

for things within the same major version that want new flags, I have the
start of the script search through --interface or --xml-description and
exit with an error if the GRASS version is too old.
e.g. see the g6/r.out.kml addon script.

I'm not proposing either of those for a formal solution as it doesn't
help compiled C modules, but fwiw that's my workaround for version-
proofing my personal scripts.

$HOME/.grass6/addons or
$AppData\GRASS<major_version>\addons

I would suggest to change `addons` to
`addons<full_version>`,
concretely GRASS 6.4.2 addons would be installed to

$HOME/.grass6/addons642 or
$AppData\GRASS<major_version>\addons642

and GRASS 6.5 to

$HOME/.grass6/addons65 or
$AppData\GRASS<major_version>\addons65

What do you think?

the path name gets a bit long, but for compiled code it
seems necessary and I have no better suggestion on how to
improve that or work around it.

Other thing is that g.extension (or it's wxGUI front-end) should
automatically ask user to update his/her extensions when you upgrade
GRASS (libgis revision must be same for GRASS and the addons).

the classic way would be a g.extension.rebuild script, along the lines
of v.build.all or v.in.sites.all. perhaps the best solution would be
to have the GUI tick box or button or automatic popup dialog call that
generally installed script for backend processing. (so you don't need
a GUI to upgrade processing modules your headless server)

I guess the new ~/.grass6/wx[_config] file could have an entry for
'first time with this ver?' set to 0 or 1 and prompt you on startup
if it was set to 0, then scan the addons modules.xml file for candidates.
(or store x.y.z part of version string that created the ~/.grass6/wx
file IN the wx file and test against that)

switching back and forth between versions all day as I do, I can see
how clicking [no, leave me alone] 10 times a day would get annoying
very quickly.

store current version in the $addons/modules.xml file?
or maybe better within each individual xml <module> entry?
shrug

..
how well does the ~/.grass6/wx config file cope with added/removed
options if the config file is more than one or two versions out of date?
I've seen too many times to recall other C/C++ GUI apps crashing because
of that issue. It's very nice to have your preferences carry through,
but will those wx files stay forward+backward compatible for all .grass6/
and .grass7/ ?

2c,
Hamish

ps- outstanding question: should sudo/system wide installs of addons
done with g.extension.py be allowed to delete files from the main
$GISBASE base or not?

[martinl]

Hi,

2011/12/14 Michael Barton <michael.barton@asu.edu>:

All directories that begin with a "." are by default hidden from Mac users. Since permissions and settings can be accessed in other ways, this is not a big problem.

it's same for GNU/Linux, bear in mind that Mac OS has the roots in Unix

But if we are putting addons into the same hidden directory, it is more troublesome.

Why? Most of the application store it's settings / user data in hidden
directories (GNU/Linux).

William has previously put this into the /Library folder as a visible folder. This is a much more sensible place for the Mac. So we need to treat Mac's differently from Linux, like we do Windows.

On Windows we have different reason, directories starting with '.' are
not used on this system. I would incline to install addons in the same
directory as the settings (rc, wx, ...) - speaking about GRASS 7.

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

[cmbarton]

My rationale is that I and others use the addons directory as a place to store our own bash/python scripts. These are not installed by g.extension. It is a royal pain putting them into a hidden directory and managing them there. Many Mac users do not know how to access such hidden directories. Even it you do, you cannot use the finder to do so without altering all hidden directories with a script. You can access such directories in the GUI file systems of linux systems I've used.

Michael
______________________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

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

On Dec 14, 2011, at 2:22 PM, Martin Landa wrote:

Hi,

2011/12/14 Michael Barton <michael.barton@asu.edu>:

All directories that begin with a "." are by default hidden from Mac users. Since permissions and settings can be accessed in other ways, this is not a big problem.

it's same for GNU/Linux, bear in mind that Mac OS has the roots in Unix

But if we are putting addons into the same hidden directory, it is more troublesome.

Why? Most of the application store it's settings / user data in hidden
directories (GNU/Linux).

William has previously put this into the /Library folder as a visible folder. This is a much more sensible place for the Mac. So we need to treat Mac's differently from Linux, like we do Windows.

On Windows we have different reason, directories starting with '.' are
not used on this system. I would incline to install addons in the same
directory as the settings (rc, wx, ...) - speaking about GRASS 7.

Martin

--
Martin Landa <landa.martin gmail.com> * Studijní program Geodézie a kartografie – GeoWikiCZ

[martinl]

Hi,

2011/12/14 Michael Barton <Michael.Barton@asu.edu>:

My rationale is that I and others use the addons directory as a place to store our own bash/python scripts. These are not installed by g.extension. It is a royal pain putting them into a hidden directory and managing them there. Many Mac users do not know how to access such hidden directories. Even it you do, you cannot use the finder to do so without altering all hidden directories with a script. You can access such directories in the GUI file systems of linux systems I've used.

you can put it everywhere you want and then modify GRASS_ADDON_PATH to
point to this directory. Probably wxGUI could have some extra
functionality for that - install local scripts.

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

[martinl]

2011/12/14 Martin Landa <landa.martin@gmail.com>:

My rationale is that I and others use the addons directory as a place to store our own bash/python scripts. These are not installed by g.extension. It is a royal pain putting them into a hidden directory and managing them there. Many Mac users do not know how to access such hidden directories. Even it you do, you cannot use the finder to do so without altering all hidden directories with a script. You can access such directories in the GUI file systems of linux systems I've used.

This is not really the reason why g.extension should not install
extensions to the hidden directory

you can put it everywhere you want and then modify GRASS_ADDON_PATH to
point to this directory. Probably wxGUI could have some extra
functionality for that - install local scripts.

What about wxGUI's 'File -> Launch script'

This function could

* check if directory with the script is in GRASS_ADDON_PATH
* if not ask user whether he/she wants to add this directory to
GRASS_ADDON_PATH (.grass.bashrc for G6 or .grass7/bashrc for G7)

What do you think?

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

[cmbarton]

OK. Then perhaps I misunderstood the discussion here.

Michael
______________________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

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

On Dec 14, 2011, at 2:29 PM, Martin Landa wrote:

Hi,

2011/12/14 Michael Barton <Michael.Barton@asu.edu>:

My rationale is that I and others use the addons directory as a place to store our own bash/python scripts. These are not installed by g.extension. It is a royal pain putting them into a hidden directory and managing them there. Many Mac users do not know how to access such hidden directories. Even it you do, you cannot use the finder to do so without altering all hidden directories with a script. You can access such directories in the GUI file systems of linux systems I've used.

you can put it everywhere you want and then modify GRASS_ADDON_PATH to
point to this directory. Probably wxGUI could have some extra
functionality for that - install local scripts.

Martin

--
Martin Landa <landa.martin gmail.com> * Studijní program Geodézie a kartografie – GeoWikiCZ

[martinl]

2011/12/15 Michael Barton <Michael.Barton@asu.edu>:

OK. Then perhaps I misunderstood the discussion here.

I was speaking about situation when you have more GRASS versions
installed (let's say 6.4.2 and 6.5) and you are installing extension
using `g.extension`. Currently it's installed to the same directory
(if not defined by user). - `.grass6/addons`. That need to be changed,
I suggested `addons<full_version>` in this case GRASS 642 ->
`.grass6/addons642` and GRASS 65 -> `grass6/addons65`.

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

[Hamish]

Martin wrote:

* if not ask user whether he/she wants to add this
directory to GRASS_ADDON_PATH (.grass.bashrc for G6 or
.grass7/bashrc for G7)

it doesn't work to put GRASS_ADDON_PATH into .grass.bashrc,
you need to export it from your ~/.bashrc or ~/.profile.
(and it is too invasive to start appending to those automatically)

it needs to be set before init.sh/grass.py gets run.

my plan for trunk was to rename GRASS_ADDON_PATH (taken over
by g.extension.py) to GRASS_ADDON_BASE, then re-add
GRASS_ADDON_PATH as a $PATH component, if it exists. if it was
not already set then nothing is added to the environment.. it's
there if you want to use it, and not if you don't.

that does not preclude the wxGUI having a Preference setting
to add some dirs to the copy of the $PATH it maintains, starting
with any existing GRASS_ADDON_PATH enviro variable that was
there when it launched.

Hamish

[cmbarton]

The way that William had it set is that the default locations for addons were defined as /Library/GRASS/6.4 or /Library/GRASS/6.5 etc. The system and/or user /Library folder is the normal place for preferences, plugins, and other such files on a Mac. While the Mac is Unix at heart, people don't interact with its OS and file system in the same way Linux users do. If there are things we want to hide from normal users, then using a hidden directory is OK. But for addons, it is better to put them in a place where users expect to find them. FWIW, it would be better if preferences were in /Library too because that's where they are for other software.

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 Dec 14, 2011, at 4:19 PM, Martin Landa wrote:

2011/12/15 Michael Barton <Michael.Barton@asu.edu>:

OK. Then perhaps I misunderstood the discussion here.

I was speaking about situation when you have more GRASS versions
installed (let's say 6.4.2 and 6.5) and you are installing extension
using `g.extension`. Currently it's installed to the same directory
(if not defined by user). - `.grass6/addons`. That need to be changed,
I suggested `addons<full_version>` in this case GRASS 642 ->
`.grass6/addons642` and GRASS 65 -> `grass6/addons65`.

Martin

--
Martin Landa <landa.martin gmail.com> * Studijní program Geodézie a kartografie – GeoWikiCZ

[cmbarton]

On Dec 14, 2011, at 5:48 PM, Hamish wrote:

Martin wrote:

* if not ask user whether he/she wants to add this
directory to GRASS_ADDON_PATH (.grass.bashrc for G6 or
.grass7/bashrc for G7)

it doesn't work to put GRASS_ADDON_PATH into .grass.bashrc,
you need to export it from your ~/.bashrc or ~/.profile.
(and it is too invasive to start appending to those automatically)

It is not good to mess with these on the Mac unless you know what you are doing. That rules out most Mac users.

it needs to be set before init.sh/grass.py gets run.

my plan for trunk was to rename GRASS_ADDON_PATH (taken over
by g.extension.py) to GRASS_ADDON_BASE, then re-add
GRASS_ADDON_PATH as a $PATH component, if it exists. if it was
not already set then nothing is added to the environment.. it's
there if you want to use it, and not if you don't.

that does not preclude the wxGUI having a Preference setting
to add some dirs to the copy of the $PATH it maintains, starting
with any existing GRASS_ADDON_PATH enviro variable that was
there when it launched.

All this is fine. However, GRASS_ADDON_BASE should not be a hidden file on a Mac. It is problem enough that preferences are there if you ever have to mess with them outside of the GRASS GUI.

Michael

Hamish

[martinl]

2011/12/15 Hamish <hamish_b@yahoo.com>:

Martin wrote:

* if not ask user whether he/she wants to add this
directory to GRASS_ADDON_PATH (.grass.bashrc for G6 or
.grass7/bashrc for G7)

it doesn't work to put GRASS_ADDON_PATH into .grass.bashrc,
you need to export it from your ~/.bashrc or ~/.profile.
(and it is too invasive to start appending to those automatically)

hm, and what's the purpose or `.grass.bashrc` I thought it should be a
place for GRASS-related (bash) env variables (for G7 it should be
probably `.grass7/bashrc`). Why to modify ~/.bashrc or ~/.profile
directly (it seems to me quite invasive;-)

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

[martinl]

2011/12/15 Michael Barton <Michael.Barton@asu.edu>:

it doesn't work to put GRASS_ADDON_PATH into .grass.bashrc,
you need to export it from your ~/.bashrc or ~/.profile.
(and it is too invasive to start appending to those automatically)

It is not good to mess with these on the Mac unless you know what you are doing. That rules out most Mac users.

well, not only Mac-users

it needs to be set before init.sh/grass.py gets run.

my plan for trunk was to rename GRASS_ADDON_PATH (taken over
by g.extension.py) to GRASS_ADDON_BASE, then re-add
GRASS_ADDON_PATH as a $PATH component, if it exists. if it was
not already set then nothing is added to the environment.. it's
there if you want to use it, and not if you don't.

that does not preclude the wxGUI having a Preference setting
to add some dirs to the copy of the $PATH it maintains, starting
with any existing GRASS_ADDON_PATH enviro variable that was
there when it launched.

All this is fine. However, GRASS_ADDON_BASE should not be a hidden file on a Mac. It is problem enough that preferences are there if you ever have to mess with them outside of the GRASS GUI.

There is no GRASS_ADDON_BASE. Anyway it should be controlled only by
`g.extension` (user scripts can live somewhere else). So basically
there is no problem that g.extension installs extensions to the hidden
directory.

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

[martinl]

2011/12/15 Martin Landa <landa.martin@gmail.com>:

All this is fine. However, GRASS_ADDON_BASE should not be a hidden file on a Mac. It is problem enough that preferences are there if you ever have to mess with them outside of the GRASS GUI.

There is no GRASS_ADDON_BASE. Anyway it should be controlled only by
`g.extension` (user scripts can live somewhere else). So basically
there is no problem that g.extension installs extensions to the hidden
directory.

anyway Mac-users should decide, it should be controlled here [1] - I
don't see any special settings for Mac.

Martin

[1] http://trac.osgeo.org/grass/browser/grass/trunk/lib/init/grass.py#L333

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

[cmbarton]

OK. That all sounds fine. Thanks.

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 Dec 14, 2011, at 6:39 PM, Martin Landa wrote:

2011/12/15 Martin Landa <landa.martin@gmail.com>:

All this is fine. However, GRASS_ADDON_BASE should not be a hidden file on a Mac. It is problem enough that preferences are there if you ever have to mess with them outside of the GRASS GUI.

There is no GRASS_ADDON_BASE. Anyway it should be controlled only by
`g.extension` (user scripts can live somewhere else). So basically
there is no problem that g.extension installs extensions to the hidden
directory.

anyway Mac-users should decide, it should be controlled here [1] - I
don't see any special settings for Mac.

Martin

[1] grass.py in grass/trunk/lib/init – GRASS GIS

--
Martin Landa <landa.martin gmail.com> * Studijní program Geodézie a kartografie – GeoWikiCZ

[Hamish]

Hamish wrote:

> it doesn't work to put GRASS_ADDON_PATH into .grass.bashrc,
> you need to export it from your ~/.bashrc or ~/.profile.
> (and it is too invasive to start appending to those automatically)

Martin:

hm, and what's the purpose or `.grass.bashrc` I thought it should be a
place for GRASS-related (bash) env variables

it is, but those are run for the *grass console shell* which is launched
at the end of the init.sh process. the $PATH and things like GRASS_PYTHON
need to be set up before that console opens. there are a few others like
GRASS_BATCH_JOB which have the same restriction. see `man grass64` and
`grass64 --help` for details.

stuff gets processed then written out to to $MAPSET/.bashrc

fwiw in .grass.bashrc I have set things like PS1, HISTSIZE=3000, GRASS_WIDTH, GRASS_HEIGHT, GRASS_TRUECOLOR, GRASS_HTML_BROWSER=dillo,
GRASS_PNG_COMPRESSION=9, GRASS_PAGER=more, GRASS_NO_GLX_PBUFFERS,
GRASS_NO_GLX_PIXMAPS, and:

# first GRASS instance gets set a low priority
NUMGRASSES=`pgrep -c Init.sh`
if [ "$NUMGRASSES" -le 1 ] ; then
   renice +14 -p $$
else
   NICENESS=`echo $NUMGRASSES | awk '{printf("%0.f", 20 / $1)}'`
   renice +$NICENESS -p $$
fi

(ie so newer grass sessions get priority over older running ones, and
big processing jobs leave the computer still responsive)

some of the other enviro vars are just for historical reasons on my
machine at this point but do no harm..

Hamish

[Hamish]

[by the way, I'd love to hear feedback from Mac users about how well
g.extension(.sh) and the wxGUI extension manager performs in the latest
6.x.svn]

Michael wrote:

The way that William had it set is
that the default locations for addons were defined as
/Library/GRASS/6.4 or /Library/GRASS/6.5 etc. The system
and/or user /Library folder is the normal place for
preferences, plugins, and other such files on a Mac. While
the Mac is Unix at heart, people don't interact with its OS
and file system in the same way Linux users do. If there are
things we want to hide from normal users, then using a
hidden directory is OK. But for addons, it is better to put
them in a place where users expect to find them. FWIW, it
would be better if preferences were in /Library too because
that's where they are for other software.

fwiw, wrt the per-user ~/Library dir in Lion getting hidden, see:
  http://osxdaily.com/2011/07/22/access-user-library-folder-in-os-x-lion/

afaik the system-wide /Library is still world visible.

Hamish

[cmbarton]

Looking forward to testing.

Right now it's end of semester. Papers to grade. Papers to finish revising. Proposals to finish. Really looking forward to sabbatical in January.

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 Dec 14, 2011, at 11:12 PM, Hamish wrote:

[by the way, I'd love to hear feedback from Mac users about how well
g.extension(.sh) and the wxGUI extension manager performs in the latest
6.x.svn]

Michael wrote:

The way that William had it set is
that the default locations for addons were defined as
/Library/GRASS/6.4 or /Library/GRASS/6.5 etc. The system
and/or user /Library folder is the normal place for
preferences, plugins, and other such files on a Mac. While
the Mac is Unix at heart, people don't interact with its OS
and file system in the same way Linux users do. If there are
things we want to hide from normal users, then using a
hidden directory is OK. But for addons, it is better to put
them in a place where users expect to find them. FWIW, it
would be better if preferences were in /Library too because
that's where they are for other software.

fwiw, wrt the per-user ~/Library dir in Lion getting hidden, see:
Access User ~/Library Folder in OS X Mountain Lion & OS X Lion

afaik the system-wide /Library is still world visible.

Hamish

[cmbarton]

In preliminary tests (GRASS 6.4 svn release branch), this seems to work very well--and in fact considerably better than it does with GRASS 7/trunk at the moment. One of the extensions I test with consistently gives an install target not found error in trunk, but installs fine with 6.4 release branch.

BUT...

There remains some kind of weird problem with setting GRASS_ADDON_PATH.

By default, GRASS_ADDON_PATH is set to the desktop, followed by the various /Library and ~/Library paths. I can change it in the GRASS terminal and I can change it in the GUI, but if I use $GRASS_ADDON_PATH in g.extension, it STILL puts stuff into desktop (as the first path in $GRASS_ADDON_PATH). Moreover, I the changes made in GRASS_ADDON_PATH in the terminal do not show up when I display settings from the GUI and the changes made in GRASS_ADDON_PATH with the GUI do not show up in the terminal--and neither are registered by g.extension.

If I hard code the directory to which I want to install with g.extension, it puts stuff there. But the GRASS_ADDON_PATH is borked up on the Mac.

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 Dec 14, 2011, at 11:12 PM, Hamish wrote:

[by the way, I'd love to hear feedback from Mac users about how well
g.extension(.sh) and the wxGUI extension manager performs in the latest
6.x.svn]

Michael wrote:

The way that William had it set is
that the default locations for addons were defined as
/Library/GRASS/6.4 or /Library/GRASS/6.5 etc. The system
and/or user /Library folder is the normal place for
preferences, plugins, and other such files on a Mac. While
the Mac is Unix at heart, people don't interact with its OS
and file system in the same way Linux users do. If there are
things we want to hide from normal users, then using a
hidden directory is OK. But for addons, it is better to put
them in a place where users expect to find them. FWIW, it
would be better if preferences were in /Library too because
that's where they are for other software.

fwiw, wrt the per-user ~/Library dir in Lion getting hidden, see:
Access User ~/Library Folder in OS X Mountain Lion & OS X Lion

afaik the system-wide /Library is still world visible.

Hamish

[Hamish]

Michael wrote:

In preliminary tests (GRASS 6.4 svn release branch), this seems to work
very well--and in fact considerably better than it does with GRASS
7/trunk at the moment.

which one, the wxGUI extension tool or g.extension(.sh) from the command
line? they are independent code. AFAIK William added some extra flags
to the .sh version that are not present in the .py version, but I don't
know if they are strictly needed anymore.

One of the extensions I test with consistently gives an install target
not found error in trunk, but installs fine with 6.4 release branch.

which one? note most addon modules are only in the grass6/ section of
addons svn, and have not been ported to grass-addons/grass7/ yet.

BUT...

There remains some kind of weird problem with setting GRASS_ADDON_PATH.

By default, GRASS_ADDON_PATH is set to the desktop,

? what path exactly?
do you set GRASS_ADDON_PATH yourself before starting GRASS? if so that
one should be used and not ~/.grass6/addons/*

which version of grass (AFAIK 6.5svn and trunk are now in sync, 6.4svn
should work fine but does not contain the latest wingrass binary download
logic)

followed by the various /Library and ~/Library paths. I can
change it in the GRASS terminal and I can change it in the
GUI, but if I use $GRASS_ADDON_PATH in g.extension, it STILL
puts stuff into desktop (as the first path in
$GRASS_ADDON_PATH).

right it installs to the first dir found in $GRASS_ADDON_PATH, as it
has to pick one, might as well be the first.

Moreover, I the changes made in GRASS_ADDON_PATH in the terminal do
not show up when I display settings from the GUI and the changes
made in GRASS_ADDON_PATH with the GUI do not show up in the
terminal--and neither are registered by g.extension.

you need to set it before starting GRASS in order for it to get picked
up everywhere, preferably in ~/.profile (or whatever is appropriate
for Macs) and you need to export it there too

from the terminal, did you "export" the enviro variable as well as setting
it? otherwise it only exists in that terminal.

If I hard code the directory to which I want to install
with g.extension, it puts stuff there. But the
GRASS_ADDON_PATH is borked up on the Mac.

note that terminals and the gui do not communicate enviro vars with each
other: sibling and parent processes are indepenent, only with their direct
launched children inherit exported vars from their parent.

Hamish

[Hamish]

btw, my current feeling about the ~/.grass$MAJOR/addons$MAJOR.$MINOR.$BUGVER
specific path to protect from binary GIS_H incompatibility is that it
may be better to create a ~/.grass65/ in addition to ~/.grass64 to keep
the two separate.

The main conflict would be if users swap back and forth between 6.4 and
6.5svn. splitting them up avoids that. on the other hand users (and maybe
but not always developers) are expected to only use one version of the
stable branch at a time, and monotonically increase their stable version.

so they could run 'g.extension.refresh.all' or whatever to rebuild all
modules.xml registered C modules soon after upgrade and then be up to
date. or just g.extension as usual to manually reinstall/refresh a
previous build as needed/when needed.

6.5svn users would be expected to take care of themselves, but esentially
the same simple upgrade/rebuild path.

seems cleaner as the main (only?) ABI conflict is developers going back
and forth between 6.4 and 6.5.

what do you think?

Hamish