You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There does not appear to be a way to mock modules imported by programs that autoprogram imports. It would be nice to have a mechanism to mock modules for autoprogram.
During regular development, this isn't a problem. In order to test the code, you need to have everything installed anyway. This is more of an obstacle with documentation systems that use CI resources (e.g. readthedocs.org). If your programs have imports with heavy duty dependencies (modules like gdal/osgeo which has C dependencies), those modules and libraries need to be installed, otherwise the "import" that autoprogram does results in a ModuleNotFoundError. However, in most cases, the function that produces the argument parser that autoprogram needs to deal with probably doesn't rely on those hefty imported modules, and if there was a way to mock them, then they wouldn't need to be installed and/or compiled by CI systems that just build documentation, making documentation development easier, faster, cheaper, and contributing less to the heat death of the planet.
The sphinx.ext.autodoc extension has a autodoc_mock_imports parameter that might be a model (maybe some functions could just be used, since it is always installed with Sphinx?) which allows a user to tell autodoc to mock a set of modules. This means that those modules don't need to be installed into the CI system if it is only building the docs.
Maybe we need an autoprogram_mock_imports parameter?
The text was updated successfully, but these errors were encountered:
Actually, I think I figured out how to do this without needing to change autoprogram:
So, for example, I have a program that I want autoprogram to run on that has this import statement:
from osgeo import gdal_array
If the gdal/osgeo package isn't installed (and its C dependencies aren't properly installed), you'll get a ModuleNotFoundError: No module named 'osgeo' error when autoprogram runs.
However, if you add this in your Sphinx conf.py file:
from unittest.mock import MagicMock
sys.modules["osgeo"] = MagicMock()
Then Sphinx (and autoprogram) will run and complete just fine without gdal/osgeo needing to be installed.
Credit where credit is due: this 2012 article talks about using the old mock library for autodoc, which I was led to by this Stack Overflow article which talks about the (then new) autodoc_mock_imports configuration parameter for autodoc. And this solution is just doing the same thing, but it also happens to work for autoprogram.
There does not appear to be a way to mock modules imported by programs that autoprogram imports. It would be nice to have a mechanism to mock modules for autoprogram.
During regular development, this isn't a problem. In order to test the code, you need to have everything installed anyway. This is more of an obstacle with documentation systems that use CI resources (e.g. readthedocs.org). If your programs have imports with heavy duty dependencies (modules like gdal/osgeo which has C dependencies), those modules and libraries need to be installed, otherwise the "import" that autoprogram does results in a ModuleNotFoundError. However, in most cases, the function that produces the argument parser that autoprogram needs to deal with probably doesn't rely on those hefty imported modules, and if there was a way to mock them, then they wouldn't need to be installed and/or compiled by CI systems that just build documentation, making documentation development easier, faster, cheaper, and contributing less to the heat death of the planet.
The sphinx.ext.autodoc extension has a
autodoc_mock_imports
parameter that might be a model (maybe some functions could just be used, since it is always installed with Sphinx?) which allows a user to tell autodoc to mock a set of modules. This means that those modules don't need to be installed into the CI system if it is only building the docs.Maybe we need an
autoprogram_mock_imports
parameter?The text was updated successfully, but these errors were encountered: