mypy: Skipping analyzing "geoalchemy2.functions": module is installed, but missing library stubs or py.typed marker [import]

[pjonsson]

After updating to GeoAlchemy2 0.14.1 which mentions type annotations in the release notes, I tried removing the ignore_missing_imports exception in my pyproject.toml. Here's the output from running mypy on my source:

file.py:4: error: Skipping analyzing "geoalchemy2.functions": module is installed, but missing library stubs or py.typed marker  [import]
file.py:4: note: See https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-imports

Are the type annotations not meant for use by third parties, so this is as expected?

If it's not as expected, I can say I haven't done anything special for pytest, and mypy somehow figures out the types for that without giving me any warnings. A difference I can see is that there is a py.typed file in that tree: https://github.com/pytest-dev/pytest/tree/main/src/pytest (which was alluded to in #464 (comment)).

[adrien-berchet]

Hi @pjonsson
Thanks for your report, I just pushed a commit to add the missing py.typed file in #477 . If you have some time to run mypy with this version it would be nice, so we can confirm that it works properly.
Then I will try to push a new release soon.

[pjonsson]

@adrien-berchet I tested it locally and I now get:

file.py:4: error: Module "geoalchemy2.functions" has no attribute "ST_Intersects"  [attr-defined]

instead, which I guess means that the types work.

Are the types in _FUNCTIONS the return type? There seems to be a lot of boolean functions that are annotated as None.

[adrien-berchet]

Thanks for this test @pjonsson
The geoalchemy2.functions are mostly assigned dynamically, so I don't know if / how mypy can handle this. I'm afraid that static typing and dynamically assigned attributes may be hard to reconcile... I will see if it's possible. Otherwise you will have to ignore the geoalchemy2.functions module.

The return types stored in _FUNCTION are used by sqlalchemy, as far as I know they are not related to annotation.

[mbway]

it seems to me in this case that the functions are known ahead of time (because they are defined in the _FUNCTIONS array), so therefore a python .pyi/stub file could be provided alongside functions.py to provide the signatures for the dynamically created functions

[adrien-berchet]

Good point @mbway ! I will see how we can improve this. Or maybe you can have a look if you have some time?

[mbway]

I'm looking into it now. I minor annoyance that I've run into before on other projects is that when a package or module is called types (eg geoalchemy2.types) it really messes with the search paths since there is a module with this name in the standard library.
To trigger the issue:

• create a module in geoalchemy with import pathlib or import enum inside
• attempt to run it with python geoalchemy2/my_module.py
  you will get the error

Traceback (most recent call last):
  File "geoalchemy2/some_module.py", line 1, in <module>
    import enum
  File "/usr/lib/python3.11/enum.py", line 3, in <module>
    from types import MappingProxyType, DynamicClassAttribute
  File "geoalchemy2/types/__init__.py", line 8, in <module>
    from typing import Any
  File "/usr/lib/python3.11/typing.py", line 26, in <module>
    import contextlib
  File "/usr/lib/python3.11/contextlib.py", line 7, in <module>
    from functools import wraps
  File "/usr/lib/python3.11/functools.py", line 22, in <module>
    from types import GenericAlias
ImportError: cannot import name 'GenericAlias' from partially initialized module 'types' (most likely due to a circular import) (geoalchemy2/types/__init__.py)

so I will put the script for generating the stubs outside the package itself

[adrien-berchet]

Hi there, the new 0.14.2 release (https://pypi.org/project/GeoAlchemy2/0.14.2/) should now provide type hints.