Skip to content

Conversation

avdstaaij
Copy link

Hi! I'm using PyGLM in a library, and recently I tried to get my library to pass pyright's strict type checking. In doing so, I noticed a few issues with the provided type stubs.

Some of the issues are caused by the new (2.8.0) packaging structure of pyglm, and some are caused by omissions and mistakes in the type stub files themselves. I was a little confused at first whether I sould submit fixes to this repository or to the pyglm-typing repository, since the type stubs are now also included in the main pyglm repository directly. I eventually concluded that it would probably be best to submit fixes to the type stub files themselves to the pyglm-typing repo, and submit fixes to the packaging structure here. See my PR in pyglm-typing for my reasoning (and for the type stub file fixes). Please let me know if I should have done it differently, though!

Explanation of the changes:

  1. First of all, the main type stub file was duplicated in pyglm/__init__.pyi and pyglm-stubs/glm/__init__.pyi. I'm pretty sure that pyglm/__init__.pyi wasn't actually doing anything, since the glm objects are imported from pyglm.glm, not pyglm. I think this could be solved by renaming pyglm/__init__.pyi to pyglm/glm.pyi or pyglm/glm/__init__.pyi, but I instead opted to remove it in favor of the file in pyglm-stubs, since pyglm-stubs also contains the pyglm-typing license.

  2. In pyglm-stubs, the file pyglm-stubs/__init__.pyi was missing. This caused an error on the import from pyglm import glm. I added this file.

  3. The main stub file in pyglm-stubs used to be at pyglm-stubs/glm/__init__.pyi. This structure is more complex than needed and doesn't actually match the way that the pyglm package is structured. I changed the structure to the simpler pyglm-stubs/glm.pyi.

  4. pyglm-stubs/glm/__init__.pyi (now pyglm-stubs/glm.pyi) contained the import from PyGLM import glm_typing. This import didn't work for various reasons. The pyglm package is pyglm, not PyGLM, and even after changing this, the import could not be resolved. I wasn't sure how to fix this, since the whole construction seemed pretty magical: the stubs apparently want to import glm_typing, which refers to glm types, and thus relies on the glm stubs - a circle! And indeed, the type stubs that relied on glm_typing didn't actually work. I believe that the proper way to handle this would be to include the contents of glm_typing in pyglm-stubs/glm.pyi, but that would require changing all references to glm types from e.g. glm.vec3 to vec3, which seemed cumbersome. Instead, I copied glm_typing.py to pyglm-stubs/glm_typing.py, and changed the import in pyglm-stubs/glm.pyi to from . import glm. I'm not entirely sure why, but this does seem to work.

  5. I removed glm/py.typed. The files there don't provide types via type annotations, so I believe py.typed is not appropriate. There were actually no type hints for imports from glm at all, only for pyglm.glm, but that didn't seem like much of a problem since glm is deprecated. Note that git seems to think that I renamed glm/py.typed to pyglm-stubs/__init__.pyi, but really it's just a removal of an empty file and an addition of an empty file.

.. Well, thanks for reading that wall of text. :)

avdstaaij added a commit to avdstaaij/gdpc that referenced this pull request Mar 12, 2025
Added custom stub files to fix the issues. I've submitted the fixes
upstream as well:
esoma/pyglm-typing#5
Zuzu-Typ/PyGLM#270
@avdstaaij
Copy link
Author

My PR in pyglm-typing has been merged. I've gone ahead and added those changes to this PR as well.

@Zuzu-Typ
Copy link
Owner

Thanks for your work on this!

I hope I'll have time to look into this a bit more thoroughly soon..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants