Provide mocks for imports like autodoc?

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?

Start by reading autoprogram's import behavior and Sphinx's autodoc_mock_imports mechanism, which the issue identifies as a model. Determine the interface for configuring mocked modules and how it should affect autoprogram's imports. Done means documentation builds can avoid installing heavy dependencies while still generating the argument parser documentation.