Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Warning on read-only filesystem: ndarray.pyi stub file could not be generated #42

Closed
Lasall opened this issue Jan 23, 2025 · 3 comments · Fixed by #43
Closed

Warning on read-only filesystem: ndarray.pyi stub file could not be generated #42

Lasall opened this issue Jan 23, 2025 · 3 comments · Fixed by #43

Comments

@Lasall
Copy link

Lasall commented Jan 23, 2025

With numpydantic used in a read-only filesystem (e.g. docker container), I get the following warning:

/usr/local/lib/python3.12/site-packages/numpydantic/meta.py:66: UserWarning: ndarray.pyi stub file could not be generated: [Errno 30] Read-only file system: '/usr/local/lib/python3.12/site-packages/numpydantic/ndarray.pyi'
   warn(f"ndarray.pyi stub file could not be generated: {e}", stacklevel=1)

It would be nice to optionally disable the creation of typing information or limit it to type checkers only.

Probably the warning exists also when numpydantic is installed as root system library and then an application executes it as a user.

@sneakers-the-rat
Copy link
Collaborator

aha, yeah that being autogenerated on import was intended to facilitate plugins (rather than versioning the .pyi, if there is some plugin present in the environment, the .pyi will reflect that, etc.), but that's mostly a "leaving an opening for the future" thing for now. Root cause is ultimately the nptyping (non-python-typing) system we inherited that will be replaced in 2.0.

I had been holding off setting up env config models and loggers because it didn't seem like the project needed them yet, and i would like to do that with a bit of care. Don't have time to do that this week, but for now i'll just flip that to an ImportWarning which is ignored by default and thus shouldn't be printed in the context in that issue of just running the dockerfile.

would that work? otherwise i can handle proper logging and env config next week

@sneakers-the-rat
Copy link
Collaborator

lmk if that doesn't work/isn't what you needed <3

@Lasall
Copy link
Author

Lasall commented Jan 24, 2025

Thank you so much, your fix works perfectly fine for me!

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 a pull request may close this issue.

2 participants