<div dir="ltr"><br><br>On Thu, May 9, 2019 at 10:01 AM Panagiotis Mavrogiorgos <<a href="mailto:pmav99@gmail.com">pmav99@gmail.com</a>> wrote:<br>><br>> Thank you markus<br>><br>> 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>>><br>>> 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>><br>><br>> 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. <br>><br><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>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.<br></div>><br>> 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?<br><div><br></div><div>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.</div><div><br></div><div>Markus M<br></div></div>