[GRASS-dev] Which is the correct WIND convention for creating a new mapset?

[Markus Metz]

On Thu, May 9, 2019 at 10:01 AM Panagiotis Mavrogiorgos <pmav99 at gmail.com>
wrote:
>
> Thank you markus
>
> On Wed, May 8, 2019 at 10:54 PM Markus Metz <markus.metz.giswork at gmail.com>
wrote:
>>
>> It depends. g.mapset changes the current mapset (and location and
database). It might also create a new mapset in an existing location, but
it always switches. If that switch is not desired, GISRC must be adjusted
to the original GRASS session. G_make_mapset() is a C function and should
be used by C modules. Of course you could use it with pygrass, but pygrass
initializes the GRASS C libraries, and you need to take care that
initializations are properly updated when changing mapsets (and locations).
Creating a new mapset in an existing location is not difficult: create the
folder and copy DEFAULT_WIND from PERMANENT to WIND in the new mapset.
Maybe create a new function create_mapset() in lib/python/script/utils.py?
>
>
> Generally speaking, I think it is important that the API comes first.
Once some functionality has been implemented in a library it can then be
exposed to the end users in multiple ways (e.g. CLI, REST, whatever). Among
other things, by implementing the API first, it is much easier to test the
code + you follow DRY.
>
> This is why I mentioned "G_make_mapset()" which seems to already be
implementing this functionality and which, as you mentioned, is exposed to
Python via pygrass. The idea is that if in the future the process of
creating a mapset becomes more complicated, then we would only have to
update "G_make_mapset()". That being said I am not familiar enough with the
initialization process so I can't really argue if a pure python
implementation is needed or not.

In this particular case I think a Python implementation would help because
1) it is really simple to create a new mapset in any existing location, 2)
the overhead of using pygrass is not needed in this case: most important
developer's rule: keep it as simple as possible.
>
> Now to become more specific, as an API user, I think would find it
strange that calling the "create_mapset()" function also changes the
current mapset. I like it when things are explicit + it makes it easier to
document and test. As far as implementing "create_mapset()" in
lib/python/script/utils.py, why not move the relevant functions from
"gui/wxpython/startup/utils.py" and have the GUI code import them from the
"grass" lib?

the suggested new function "create_mapset()" should only create a new
mapset, check if it succeeded in doing so, and not change to the new
mapset. The idea is that any python code that wants to create a new mapset
does not use its own method but instead uses this new function from
lib/python/script/utils.py.

Markus M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20190510/6760bd7d/attachment.html>