[GRASS-dev] [GRASS GIS] #2681: Remove legacy meaning of LOCATION variable

[GRASS GIS]

#2681: Remove legacy meaning of LOCATION variable
-------------------------+-------------------------------------------------
  Reporter:  wenzeslaus  |      Owner:  grass-dev@…
      Type:  task        |     Status:  new
  Priority:  blocker     |  Milestone:  8.0.0
 Component:  Startup     |    Version:  svn-trunk
Resolution:              |   Keywords:  init, grass.py, interface, CLI,
       CPU:              |  environment variables
  Unspecified            |   Platform:  All
-------------------------+-------------------------------------------------

Comment (by wenzeslaus):

 Replying to [comment:1 glynn]:
 > Replying to [ticket:2681 wenzeslaus]:
 >
 > > Especially in older and stable code like `grass.py` we still keep the
 legacy `LOCATION` variable with meaning "full path to a Mapset".
 > >
 > > The bug #2679 suggests that nobody is actually using it. So, there is
 no need for keeping this for backward compatibility anymore.
 >
 > Originally, GISDBASE, LOCATION_NAME and MAPSET were actual environment
 variables. [...]

 This makes sense. Thanks for the clarification.

 > ...the startup script stopped setting the environment variables
 (r10655)... The export for LOCATION was re-added temporarily in r10790
 then removed again in r10793.

 There is some export somewhere even now. I can do:

 {{{
 GRASS > echo $LOCATION
 .../grassdata/nc_spm_08_grass7/user1
 }}}

 It seems that [source:grass/trunk/lib/init/grass.py#L1421 bash_startup()]
 is to blame. It seems that this was added in r60216. I don't see it in
 `prompt.py` which was removed in that commit.

 > None of these variables should have been exported to the environment in
 over a decade.

 And they are not. However, as described in #2679,
 [http://grass.osgeo.org/grass70/manuals/grass7.html#other-examples the
 documentation] says that you can set these environment variables including
 `LOCATION` //before// starting GRASS and that GRASS will respect them
 (i.e. store them into "gisrc" file).

 So then I would say that if #2679 functionality will be implemented
 (rather then dropped) it should be done in the way that

  * `LOCATION_NAME` is not supported
  * `LOCATION` means Location name (analogy to `MAPSET` meaning Mapset
 name)
  * `MAPSET_PATH` means full path to mapset (if implemented)
  * variables are removed from the environment by `grass.py` because no
 GRASS processes should rely on them
  * we consider prefixing all with `GRASS_`

 The documentation of `grass.py` (`grass7 --help`) can be changed without
 any harm. (As well as any source code such as `grass.py`.)

 This would leave the "gisrc" file the only occurrence of `LOCATION_NAME`.
 As I mentioned before, we cannot remove it because we've already released
 GRASS GIS 7.0 and the "gisrc" file is used as an interface when "not
 starting GRASS explicitly." We can do this for GRASS GIS 8.

 What we could do for 7 series is to introduce forward compatibility and
 provide `LOCATION` as an alternative for `LOCATION_NAME`. This would
 require changes to `g.gisenv` and related library functions but it seems
 possible (although I haven't checked source code yet).

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2681#comment:2>
GRASS GIS <http://grass.osgeo.org>