<div dir="ltr"><div dir="ltr">Thank you markus<br></div><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 8, 2019 at 10:54 PM Markus Metz <<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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?<br></div></div></blockquote><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>BTW, those functions do need a few improvements; e.g. rename_mapset() should fail to rename PERMANENT etc, but let's move them first and we can do that later.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><br><div>>>> I adjusted the wxGUI startup wizard and the tests in trunk r74472,3 (the tests should use g.mapset -c, not yet implemented)</div>><br>><br>> I think that in the nc_spm_full_v2alpha dataset WIND and DEFAULT_WIND differ, so 74473 might break any tests that don't explicitly set the region themselves (which of course they should). We will see.<br><div><br></div><div>IMHO, tests need to set the region themselves, just as users. The current region is such a fundamental concept of GRASS (raster processing) that I regard it as a mistake if the current region is not explicitly set to actual demands.<br></div></div></blockquote><div><br></div><div>I completely agree that tests that don't set the region themselves should be fixed.</div><div><br></div><div>all the best,</div><div>Panos</div></div></div>