Circumvent grass.temporal mapset issue?

[lrntct]

Hi,

Currently, grass.temporal presents issue when changing mapset from a Python script (see https://github.com/OSGeo/grass/issues/629). This is how it looks:

#!/usr/bin/env python3
# -*- coding: utf-8 -*-

import tempfile

import grass_session
import grass.script as gscript

tmpdir = tempfile.mkdtemp()


def do_something():
    import grass.temporal as tgis
    tgis.init()
    tlist = gscript.read_command('t.list')
    print(tlist)


with grass_session.Session(gisdb=tmpdir, location='xy', mapset=None,
                           create_opts='XY', loadlibs=True):
    print(gscript.read_command('g.mapset', flags='p'))
    print(gscript.read_command('g.mapsets', flags='p'))
    do_something()

with grass_session.Session(gisdb=tmpdir, location='xy', mapset='test2',
                           create_opts='XY', loadlibs=True):
    print(gscript.read_command('g.mapset', flags='p'))
    print(gscript.read_command('g.mapsets', flags='p'))
    do_something()

With the following result:

Loading libraries from /usr/lib/grass78/lib
PERMANENT

Accessible mapsets:
PERMANENT

Default TGIS driver / database set to:
driver: sqlite
database: $GISDBASE/$LOCATION_NAME/$MAPSET/tgis/sqlite.db
WARNING: Temporal database connection defined as:
         /tmp/tmp5_yjxm_j/xy/PERMANENT/tgis/sqlite.db
         But database file does not exist.
Creating temporal database: /tmp/tmp5_yjxm_j/xy/PERMANENT/tgis/sqlite.db
----------------------------------------------

Loading libraries from /usr/lib/grass78/lib
test2

Accessible mapsets:
test2 PERMANENT

Default TGIS driver / database set to:
driver: sqlite
database: $GISDBASE/$LOCATION_NAME/$MAPSET/tgis/sqlite.db
ERROR: Unable to execute sql statement. You have no permission to access
mapset <test2>, or mapset <test2> has no temporal database. Accessible
mapsets are: <PERMANENT>

Even though g.mapset and g.mapsets indicates that the mapset has been changed, and the current mapset is accessible, grass.temporal believes otherwise.

Obviously it would be better to fix this upstream, but I wonder if there could be a way to circumvent this issue in grass-session.

So far I run the code in a separate process, but I do not feel that it is the proper solution. Especially when the GRASS Session is created as part of a pytest fixture.