Deprecated app module aliases should not cause warnings when building developer documentation. #15618
Description
Is your feature request related to a problem? Please describe.
PR #13366 changed a way in which NVDA maps an app module to a given executable. In the process several old app modules were marked as deprecated (they show warnings on import). This is pretty noticeable when building developer documentation scons devDocs. The following two types of warnings are shown:
Importing appModules.digitaleditionspreview is deprecated, instead import appModules.digitaleditions.
WARNING: invalid signature for automodule ('appModules.azardi-2_0')
WARNING: don't know which module to import for autodocumenting 'appModules.azardi-2_0' (try placing a "module" or "currentmodule" directive in the document, or giving an explicit module name)
WARNING: invalid signature for automodule ('appModules.azuredatastudio-insiders')
WARNING: don't know which module to import for autodocumenting 'appModules.azuredatastudio-insiders' (try placing a "module" or "currentmodule" directive in the document, or giving an explicit module name)
WARNING: invalid signature for automodule ('appModules.code - insiders')
WARNING: don't know which module to import for autodocumenting 'appModules.code - insiders' (try placing a "module" or "currentmodule" directive in the document, or giving an explicit module name)
Describe the solution you'd like
Since these are deprecated aliases (with the exception of module for Azardi, see below) I suggest to remove them in the 2024.1 development cycle. We cannot just disable deprecated code when building developer documentation, since for most of these modules they cannot be imported by Sphinx (their names do not comply to the naming requirement of a Python module). Module for Azardi is a special case - it is not deprecated. However since we are in the backward compatibility breaking release, I suggest to just rename it into something like azardi20, and map it to the Azardi's binary.
Describe alternatives you've considered
If it is decided that keeping backward compat here is desired, it should be possible to write a custom importer which simulates presence of these modules at runtime. I'm willing to work on this, if that is the direction NV Access prefers.
Additional context
While I believe keeping backward compatibility is important, the deprecated code should not be getting in the way. I'm also not aware of any add-on which relies on presence of these deprecated app modules.