OSGeo
[grass.temporal] sqlite3 default timestamp converter and adapters are deprecated as of Python 3.12
The temporal framework uses deprecated converters and adapters:
/usr/lib/grass84/etc/python/grass/temporal/core.py:1552: DeprecationWarning: The default timestamp converter is deprecated as of Python 3.12; see the sqlite3 documentation for suggested replacement recipes
return self.cursor.fetchone()
/usr/lib/grass84/etc/python/grass/temporal/core.py:1557: DeprecationWarning: The default timestamp converter is deprecated as of Python 3.12; see the sqlite3 documentation for suggested replacement recipes
return self.cursor.fetchall()
/usr/lib/grass84/etc/python/grass/temporal/core.py:1538: DeprecationWarning: The default datetime adapter is deprecated as of Python 3.12; see the sqlite3 documentation for suggested replacement recipes
self.cursor.execute(statement, args)
The replacements recipes are here.
The amount of DeprecationWarning is substantial. For example, while running the tests for xarray-grass: 24 passed, 163 warnings.
If you know a bit on how to test it out, and know if it works, we'd be happy to review a PR for it!
I was myself unsure on where to go with this, as I don't end up using this part of the code. But I've noticed it too.
It's an issue that bothers me a bit, so I could try to fix it. However, I am not sure when I'll have time for it. Hopefully before the warnings turn to errors 😆 I can write test for the individual converter functions. The solution should not break any existing tests.
Having tests of before and after would be great, especially if this topic makes sense to you (as I said, it's not clear to me yet)! That would allow us to be more confident. If they could be closer to unit tests (only touching these parts) and not integration tests (the whole temporal processing from beginning to end) it would be faster to execute and isolate failures more.
If the deprecation warnings appeared for 3.12, we still have a bit of time. But 3.14 is going to be out this fall.
As I understand it, the timestamp converters are now implicit in GRASS, and they need to be explicit in future Python versions.
My approach to testing would be to verify if there are existing unit tests for the functions that trigger the warnings (seems to be the methods execute(), fetchone() and fetchall() in core.DBConnection), and write one if not. Then write unit tests for the new converters.
If there are some run with pytest and with code coverage enabled, download the artifact of the job, and it'll even show you which tests touch what lines. But probably none touch this with pytest