[GRASS-dev] Re: [GRASS-SVN] r49124 - grass/branches/develbranch_6/lib/init

martinl · November 8, 2011, 5:13pm

2011/11/6 <svn_grass@osgeo.org>:

Author: hamish
Date: 2011-11-06 13:32:08 -0800 (Sun, 06 Nov 2011)
New Revision: 49124

Modified:
grass/branches/develbranch_6/lib/init/init.sh
Log:
clean up GRASS_ADDON_PATH logic & convert echo to a comment. executables
are already symlinked into the main GRASS_ADDON_PATH dir; bin/ and script/
may go away soon in gr6; please don't propagate misuse of GRASS_ADDON_PATH
as an ALT_GISBASE.

Modified: grass/branches/develbranch_6/lib/init/init.sh

--- grass/branches/develbranch_6/lib/init/init.sh 2011-11-06 21:22:05 UTC (rev 49123)
+++ grass/branches/develbranch_6/lib/init/init.sh 2011-11-06 21:32:08 UTC (rev 49124)
@@ -256,10 +256,10 @@
LCL=`echo "$LANG" | sed 's/$..$$.*$/\1/'`
fi

+# if it doesn't exist set it to something so that g.extension's default is reasonable
if [ -z "$GRASS_ADDON_PATH" ] ; then
- GRASS_ADDON_PATH="$HOME/.grass6/addons/bin:$HOME/.grass6/addons/scripts"
+ GRASS_ADDON_PATH="$HOME/.grass6/addons"
export GRASS_ADDON_PATH
- echo "GRASS_ADDON_PATH undefined, using '$GRASS_ADDON_PATH'"
fi
PATH="$GISBASE/bin:$GISBASE/scripts:$GRASS_ADDON_PATH:$PATH"
export PATH

I *really* do not understand this change! It goes completely against
your opinion [1]! Moreover it causes

$ echo $GRASS_ADDON_PATH
/home/martin/.grass6/addons

$ ls ~/.grass6/addons/scripts/
i.atcorr.zodh.py

$ i.atcorr.zodh.py
bash: i.atcorr.zodh.py: command not found

Martin

PS: Now I understand what was wrong during the last remote sensing course

[1] http://lists.osgeo.org/pipermail/grass-user/2011-October/062195.html

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

Hamish · November 9, 2011, 3:37am

Hamish committed:

> - GRASS_ADDON_PATH="$HOME/.grass6/addons/bin:$HOME/.grass6/addons/scripts"
> + GRASS_ADDON_PATH="$HOME/.grass6/addons"

Martin wrote:

I *really* do not understand this change! It goes completely
against your opinion [1]!

...

[1] http://lists.osgeo.org/pipermail/grass-user/2011-October/062195.html

don't worry, the ideas are not in conflict at all--
- bin/ and script/ do not really belong in GRASS_ADDON_PATH,
because GRASS_ADDON_PATH was not meant to be GRASS_ADDON_BASE.

- g.extension.sh symlinks executables back into the main
   GRASS_ADDON_PATH from those two subdirs, and as mentioned
   a couple times already I plan to have g.extension.sh move
   them there and drop the bin/ and script/ dirs and symlinking.
   $GRASS_ADDON_PATH goes into the $PATH, so is the place for
   executables.
   the symlink part of the process seems to have failed for you.

Moreover it causes

$ echo $GRASS_ADDON_PATH
/home/martin/.grass6/addons

$ ls ~/.grass6/addons/scripts/
i.atcorr.zodh.py

$ i.atcorr.zodh.py
bash: i.atcorr.zodh.py: command not found

apparently the symlink back to GRASS_ADDON_PATH did not get made
for the python script?

near the end of g.extension.sh:
   if [ "$MYINST_DIR" = "$GRASS_ADDON_PATH1" ] ; then
      # symlink into path which is actually in the $PATH
      ln -s "$MYINST_DIR/$PROGTYPE/$MODULE" "$MYINST_DIR/"
   fi

but for the case where $GRASS_ADDON_PATH did not already exist,
$MYINST_DIR is "$GRASS_ADDON_PATH" while "$GRASS_ADDON_PATH1"
is probably like "~/.grass6/addons".

probably not hard to fix with a little "set -x", but installing
to the main ADDON_PATH instead of bin/ and script/ (from .tmp/)
will fix it too and is my preferred solution as it simplifies
the situation.

regards,
Hamish

martinl · November 16, 2011, 5:02pm

Hi,

2011/11/9 Hamish <hamish_b@yahoo.com>:

don't worry, the ideas are not in conflict at all--
- bin/ and script/ do not really belong in GRASS_ADDON_PATH,
because GRASS_ADDON_PATH was not meant to be GRASS_ADDON_BASE.

no worries here, just you reverted something which was working. Please
note that your strict option about GRASS_ADDON_PATH hasn't been
supported by any other developer! I feel creating symlinks as weird
workaround which for eg. on Windows means that you will create copy of
the file in `addons` directory when installing extension using
`g.extension`. Your revert just made things more complicated again.
Nothing else.

Martin

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

Hamish · November 19, 2011, 6:36am

Hamish:

> - bin/ and script/ do not really belong in
> GRASS_ADDON_PATH,because GRASS_ADDON_PATH was
> not meant to be GRASS_ADDON_BASE.

Martin:

no worries here, just you reverted something
which was working.

It was an unneeded work around for another problem
that had since been fixed.

Your revert just made things more complicated
again.
Nothing else.

basically what happened is that when you hardcoded
~/.grass6/addons/ as the default destination it
broke the test which created the symlinks, and so
the built modules could not be found in the PATH.

Your change to init.sh then tried to work around
this problem by adding bin/ and script/ into the
PATH too.

In concert with r49124 I had also fixed the
g.extension test so that the symlink creation
worked again, and so the work-around hack was no
longer needed. thus the revert.

Maybe I could have explained that better before, but
AFAIK now everything should function ok.

as mentioned earlier, and in the commit log message,
there's no need to _install_ to bin/ and script/,
so instead of symlinks my (grass6) plan is in future
to install them all into the GRASS_ADDON_PATH dir
directly, and then we can skip the symlink work-
around, simplifying things further, and hopefully
making everyone happy.

I just want to confirm that all is good in the
devbr6 version of g.extension.sh and backport the
latest changes to establish a known-good delta
before making those new invasive changes to this
rather delicate module.

Please note that GRASS_ADDON_PATH as "set additional
path(s) to local GRASS modules" (ie add to $PATH)
has been a part of the codebase for 10 years. I was
surprised it had been that long, but that's what
the commit log says.. time flies like an arrow,
fruit flies like a banana. The re-tasking of it by
g.extension is a very modern phenomenon, and if we
can make g.extension cleanly support the established
expectation of how it works, we should do that.

regards,
Hamish