[GRASS-dev] where to store GRASS settings: GISRC and wx settings

GRASS GIS GRASS GIS developer
1

Looking at trunk, 6.5 and 6.4.2, there is inconsistency both within
and between branches where to store settings. While 6.4 usually stores
GISRC in $HOME/.grassrc6 and wx settings in $HOME/.grasswx6, the
recent wxGUI prefers $HOME/.grass6/wx on Linux and Mac and
$APPDATA/.grass6/wx on Windows. In trunk, these settings are stored in
.grass7/rc and .grass7/wx. The .grass7 folder is supposed to be in
$HOME (start up script) and $APPDATA (wxGUI under Windows). This is a
bit of a mess.

Lastly, a leading point makes MS Windows rather unhappy, i.e. is not
allowed and removed or the directory is not created at all (XP +
NTFS), thus .grass7 or .grass6, no matter where they are supposed to
live do not exist. I think that might have worked when these
files/folders where living under MS Windows in the MSYS home and not
the regular MS Windows home which has now been abandoned for good
reason (write permissions).

Therefore I suggest to use

$HOME/.grass<MAJORVERSION>/rc and $HOME/.grass<MAJORVERSION>/wx on
everything but MS Windows

and

$APPDATA/grass<MAJORVERSION>/rc and $APPDATA/grass<MAJORVERSION>/wx on
MS Windows

Tired of testing on MS Windows,

Markus M

2

Hi,

2011/8/29 Markus Metz <markus.metz.giswork@googlemail.com>:

Looking at trunk, 6.5 and 6.4.2, there is inconsistency both within
and between branches where to store settings. While 6.4 usually stores
GISRC in $HOME/.grassrc6 and wx settings in $HOME/.grasswx6, the

right, it was true for <= 6.4.1. Starting with 6.4.2 it's .grass6/wx, see [1].

Therefore I suggest to use

$HOME/.grass<MAJORVERSION>/rc and $HOME/.grass<MAJORVERSION>/wx on
everything but MS Windows

and

$APPDATA/grass<MAJORVERSION>/rc and $APPDATA/grass<MAJORVERSION>/wx on
MS Windows

Agreed, Martin

[1] http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/gui/wxpython/gui_modules/preferences.py#L64

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

3

On Mon, Aug 29, 2011 at 7:15 PM, Martin Landa <landa.martin@gmail.com> wrote:

Hi,

2011/8/29 Markus Metz <markus.metz.giswork@googlemail.com>:

Looking at trunk, 6.5 and 6.4.2, there is inconsistency both within
and between branches where to store settings. While 6.4 usually stores
GISRC in $HOME/.grassrc6 and wx settings in $HOME/.grasswx6, the

right, it was true for <= 6.4.1. Starting with 6.4.2 it's .grass6/wx, see [1].

Therefore I suggest to use

$HOME/.grass<MAJORVERSION>/rc and $HOME/.grass<MAJORVERSION>/wx on
everything but MS Windows

and

$APPDATA/grass<MAJORVERSION>/rc and $APPDATA/grass<MAJORVERSION>/wx on
MS Windows

I just noticed that the grass7 NSIS script replaced .grass7 with
GRASS7, probably because it is not possible to create a .grass7
directory in $APPDATA, only a grass7 or GRASS7 directory. Trying to
simplify now.

Markus M

4

Markus Metz wrote:

Therefore I suggest to use

$HOME/.grass<MAJORVERSION>/rc
[...] on everything but MS Windows

re. ~/.grassrc6, do not mess with the location of longstanding
support files. 6.x is the **stable** branch which should have
its core firmly in bug-fix-only mode.

trunk, MS Windows, wxGUI: they do not have the many years of
assumptions built upon them, both by us, our users' personal
scripts, and 3rd parties; so do what improvements you like.
(.grass6/wx etc, and .grass7/all sounds good to me)

thanks,
Hamish

5

Hi,

2011/8/29 Hamish <hamish_b@yahoo.com>:

re. ~/.grassrc6, do not mess with the location of longstanding
support files. 6.x is the **stable** branch which should have
its core firmly in bug-fix-only mode.

6.4 is stable branch, not 6.5. Anyway it will not brake anything, old
location of rc/wx file is read, GRASS just stores new files on other
position. Nothing is going to broken. It's better to make current mess
smaller then to leave as it is.

Martin

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

6

On Mon, Aug 29, 2011 at 9:57 PM, Martin Landa <landa.martin@gmail.com> wrote:

Hi,

2011/8/29 Hamish <hamish_b@yahoo.com>:

re. ~/.grassrc6, do not mess with the location of longstanding
support files. 6.x is the **stable** branch which should have
its core firmly in bug-fix-only mode.

6.4 is stable branch, not 6.5. Anyway it will not brake anything, old
location of rc/wx file is read, GRASS just stores new files on other
position. Nothing is going to broken. It's better to make current mess
smaller then to leave as it is.

I have applied the suggested changes to 7 and 6.5. 6.4 needs some
modification because the wxGUI is not in sync with the lib/init code.
I tend to adjust the 6.4 wxGUI to lib/init and not vice versa, i.e.
leaving GISRC where it is for 6.4 and using 6.5 as testing ground.

Markus M

7

Hamish:

>> re. ~/.grassrc6, do not mess with the location of
>> longstanding support files. 6.x is the **stable** branch
>> which should have its core firmly in bug-fix-only mode.

[I'm just talking about the ~/.grassrc6 gisenv file on unix here]

Martin:

> 6.4 is stable branch, not 6.5.

I completely and utterly disagree with that idea. 6.5 is where
we safely test things before backporting to stable 6.4.
Design changes will not go into 6.4 so do not belong in 6.5.

> Anyway it will not brake anything,

History shows that messing with long-held assumptions will
always have unthought-of consequences. You can't assume that
others are not relying on that file for something, and that we
have thought of everything. But you can rely on the opposite
being true in both cases.

> old location of rc/wx file is read, GRASS just stores new
> files on other position. Nothing is going to broken.

multiple files scattered in the file system both doing the same
thing under different contexts and only active if other files
exist or not. what a mess!

> It's better to make current mess smaller then to leave as
> it is.

This is creating a new mess.

Markus M:

I have applied the suggested changes to 7 and 6.5.

please revert unix ~/.grassrc6 bits of r47956 for 6.5 immediately.

i.e. leaving GISRC where it is for 6.4 and using 6.5 as
testing ground.

testing ground for what? a change which will never be backported
into 6.4? I said about a year ago after we released 6.4.0 and
the flood of backports went into 6.4svn that I was going to get
increasingly cranky about >6.4.1 being for bug fixes only, and
I did mean it. Sure if there's a new flag or something which
helps make things nicer without affecting anything else we
should consider it, but changes to the core file structure for
aesthetic reasons only? No friggin way.

more than anything, my main complaint is if it ain't broke,
don't fix it:

** PUT NEW DEVELOPMENT IN TRUNK AND LEAVE 6.x WELL ENOUGH ALONE

thanks,
Hamish

8

2011/8/29 Hamish <hamish_b@yahoo.com>:

Hamish:

>> re. ~/.grassrc6, do not mess with the location of
>> longstanding support files. 6.x is the **stable** branch
>> which should have its core firmly in bug-fix-only mode.

[I'm just talking about the ~/.grassrc6 gisenv file on unix here]

Martin:

> 6.4 is stable branch, not 6.5.

I completely and utterly disagree with that idea. 6.5 is where
we safely test things before backporting to stable 6.4.
Design changes will not go into 6.4 so do not belong in 6.5.

to avoid never-ending discussion, I am not speaking about design
changes (which should be done in trunk, for that we need active
developers). Stable doesn't mean frozen, it was just what I wanted to
say.

Martin

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

9

2011/8/29 Hamish <hamish_b@yahoo.com>:

please revert unix ~/.grassrc6 bits of r47956 for 6.5 immediately.

disagreed. Martin

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

10

Hamish:

> please revert unix ~/.grassrc6 bits of r47956 for 6.5
> immediately.

Martin:

disagreed. Martin

if our opinions cancel each other out, the matter is up to the
consensus of the rest of the group then.

best,
Hamish

11

2011/8/29 Hamish <hamish_b@yahoo.com>:

Hamish:

> please revert unix ~/.grassrc6 bits of r47956 for 6.5
> immediately.

Martin:

disagreed. Martin

if our opinions cancel each other out, the matter is up to the
consensus of the rest of the group then.

it's just my opinion, not a veto. It's open for discussion (other devs
should also response), I just support the given change.

Martin

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

12

2011/8/29 Hamish <hamish_b@yahoo.com>:

Hamish:

> please revert unix ~/.grassrc6 bits of r47956 for 6.5
> immediately.

Martin:

disagreed. Martin

if our opinions cancel each other out, the matter is up to the
consensus of the rest of the group then.

well "immediately" sounds quite strongly. Well, let me say

"""
please don't revert r47956, just not immediately
"""

:wink:

Martin

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

13

Hamish wrote:

** PUT NEW DEVELOPMENT IN TRUNK AND LEAVE 6.x WELL ENOUGH ALONE

+1

Can we please make an effort to "finish" the 6.x branch. I'd really
like to see 7.0.0 released before the heat death of the universe.

--
Glynn Clements <glynn@gclements.plus.com>

14

2011/8/29 Glynn Clements <glynn@gclements.plus.com>:

** PUT NEW DEVELOPMENT IN TRUNK AND LEAVE 6.x WELL ENOUGH ALONE

+1

Can we please make an effort to "finish" the 6.x branch. I'd really
like to see 7.0.0 released before the heat death of the universe.

right me too! Anyway it will take some time (e.g nobody is working on
redesigning raster library as it was planned for 7.0). Unfortunately
there is no solid roadmap for G7, or at least what should G7 bring
new. I am afraid that 6.x will be maintained longer that we would
wish.

Martin

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

15

Uh. Oh. (Can we all come together to have a fist fight? Winner makes
decisions of all...)
Just some comments.

I don't see 6.5 as a "stable" version. For me fiddling around with
it's code base seems to be OK. Still r47956 breaks rule "Open to bug
fixes and non-structural enhancements which do not break backwards
compatibility with 6.x" set up in our roadmap [1]. Either of them have
to go.

We should think twice before grabbing random features from 7 and
pulling into 6.5 and 6.5 pulling into 6.4. Last one is the most
dangerous (not talking about direct pulls from 7 to 6.4). Leave 6.4
alone - it should be stable and not randomcoolstuff from 7.

As GRASS 7 seems to be released "when it's ready", it might not happen
before the heat death of universe, as we have no exact checklist to
tell if it is ready. We have a nice list of ideas, still I haven't
seen yet a definite list with exact features that should be done
before 7 is considered to be ready. There is a risk with such approach
too - I would like to see raster enhancements, still if nobody is
working on that - we will never have a 7.0 :wink: This risk can be
minimized by setting up some arbitrary deadline - if feature is not in
good WIP state, it has to wait till next release. Let's not make
another Hurd.

Maris.

1. http://grass.osgeo.org/wiki/Release_Roadmap#GRASS_6.5.x_and_beyond

2011/8/30 Martin Landa <landa.martin@gmail.com>:

2011/8/29 Glynn Clements <glynn@gclements.plus.com>:

** PUT NEW DEVELOPMENT IN TRUNK AND LEAVE 6.x WELL ENOUGH ALONE

+1

Can we please make an effort to "finish" the 6.x branch. I'd really
like to see 7.0.0 released before the heat death of the universe.

right me too! Anyway it will take some time (e.g nobody is working on
redesigning raster library as it was planned for 7.0). Unfortunately
there is no solid roadmap for G7, or at least what should G7 bring
new. I am afraid that 6.x will be maintained longer that we would
wish.

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

16

On Mon, Aug 29, 2011 at 11:11 PM, Hamish <hamish_b@yahoo.com> wrote:

Hamish:

> please revert unix ~/.grassrc6 bits of r47956 for 6.5
> immediately.

Martin:

disagreed. Martin

if our opinions cancel each other out, the matter is up to the
consensus of the rest of the group then.

If the discussion is going on like this, the heat death of the
universe is coming faster than we think...

In general I think it is a good idea to have all the settings and
other stuff, e.g. grass-addons, in one single folder, and not
scattered around. But that is a design change already implemented in
grass7.

Since there seems to be a majority to not introduce these changes to
6.x, I will revert the changes I did to 6.5 and also change some
backports from trunk to 6.x regarding the file where wxGUI settings
are stored, i.e. 6.x shall use .grasswx6 as in pre-6.4.2.

The status quo is thus for 6.x
use .grassrc6 and .grasswx6, located in $HOME (%USERPROFILE% for Windows)

and for 7
use .grass7/rc and .grass7/wx, located in $HOME (grass7\rc and
grass7\wx, located in %APPDATA% for Windows)

BTW, the NSIS script for the Windows installer should IMHO not change
the location and file name of GISRCRC, this should be defined at as
few places as possible for easier maintenance (grass.py for trunk).

Markus M

17

2011/8/30 Markus Metz <markus.metz.giswork@googlemail.com>:

if our opinions cancel each other out, the matter is up to the
consensus of the rest of the group then.

If the discussion is going on like this, the heat death of the
universe is coming faster than we think...

unfortunately the discussion is going like this everytime you touch
holy cow - GRASS 6.4 :wink: That's frustrating, on the other hand it
forces you to develop GRASS 7;-) Nothing to say more.

Martin

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

18

Markus Metz wrote:

In general I think it is a good idea to have all the
settings and other stuff, e.g. grass-addons,

sorry to complicate the discussion, but fwiw the meaning of the
grass-addons dir is another unresolved issue we'lll need to deal
with-- it started life as something user defined to concatenate
onto $PATH, but now is also used like --prefix=, and so we have
this confusing hybrid of both.

in one single folder, and not scattered around. But that is a
design change already implemented in grass7.

Since there seems to be a majority to not introduce these
changes to 6.x, I will revert the changes I did to 6.5 and also
change some backports from trunk to 6.x regarding the file
where wxGUI settings are stored, i.e. 6.x shall use .grasswx6
as in pre-6.4.2.

to clarify what I meant & why-

I'm not so concerned about ~/.grasswx6, as that's quite new
and not as likely to be accessed by user's own scripts,
literature, experience & expectations where to find things when
things break (1,000 archive posts telling people to remove/edit
that file if it gets broken), etc.

What I am really really concerned about is changing ~/.grassrc6,
which is a core file that has stood like that since 6.0, 6.2,
6.3.0, 6.4, and 'til now all our hard efforts to maintain
compatibility through all the grass 6 line has been unwaivering*.

[*] A notable compatibility exception was the vector/dbln file
format which we necessarily had to change to allow for spaces
in path names, but I think the solution we finally came to
helped the transition happen without any ill effects or anyone
really noticing.

While not really relevant beyond the "it was like that in 6.x for
historical reasons" understanding, fwiw I'd mention ~/.grassrc5
and for earlier grass 4 "~/.grassrc" have been there since the
1990s, and perhaps the 1980s too? since stability = discipline *
time, and one of our great strengths is time. whenever we cut
old roots and reset that clock to 0 it's a great loss to one of
our core assets.

thanks,
Hamish

19

On Wed, Aug 31, 2011 at 1:37 AM, Hamish <hamish_b@yahoo.com> wrote:

Markus Metz wrote:

In general I think it is a good idea to have all the
settings and other stuff, e.g. grass-addons,

sorry to complicate the discussion, but fwiw the meaning of the
grass-addons dir is another unresolved issue we'lll need to deal
with-- it started life as something user defined to concatenate
onto $PATH, but now is also used like --prefix=, and so we have
this confusing hybrid of both.

That's why I suggested to store all per-user settings in one single
folder: .grass7/

in one single folder, and not scattered around. But that is a
design change already implemented in grass7.

Since there seems to be a majority to not introduce these
changes to 6.x, I will revert the changes I did to 6.5 and also
change some backports from trunk to 6.x regarding the file
where wxGUI settings are stored, i.e. 6.x shall use .grasswx6
as in pre-6.4.2.

to clarify what I meant & why-

I'm not so concerned about ~/.grasswx6, as that's quite new
and not as likely to be accessed by user's own scripts,
literature, experience & expectations where to find things when
things break (1,000 archive posts telling people to remove/edit
that file if it gets broken), etc.

What I am really really concerned about is changing ~/.grassrc6,
which is a core file that has stood like that since 6.0, 6.2,
6.3.0, 6.4, and 'til now all our hard efforts to maintain
compatibility through all the grass 6 line has been unwaivering*.

Agreed. I have reverted the changes to 6.5 yesterday.

While not really relevant beyond the "it was like that in 6.x for
historical reasons" understanding, fwiw I'd mention ~/.grassrc5
and for earlier grass 4 "~/.grassrc" have been there since the
1990s, and perhaps the 1980s too? since stability = discipline *
time, and one of our great strengths is time. whenever we cut
old roots and reset that clock to 0 it's a great loss to one of
our core assets.

? Is there somewhere in 6.x a check for the presence of .grassrc5 or
.grassrc if .grassrc6 is not existing?

There seems to be a reason why .grassrc6 is hidden, users are not
meant to know about its presence or even to hand-edit this file. If
the location or name of the rc file changes as for 7, all is needed is
once starting GRASS and defining GISDBASE, LOCATION_NAME, MAPSET.

I guess your objection is not so much about this particular file but
more general about not introducing changes of this kind to 6.x. IMHO,
changes to this file are less serious than changes to the API which
already took place from 6.4.0 to 6.4.2.

Markus M