Deprecated app module aliases should not cause warnings when building developer documentation. #15618
Labels
audience/nvda-dev
PR or issue is relevant to NVDA / Add-on developers
p4
https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority
triaged
Has been triaged, issue is waiting for implementation.
Milestone
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: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.
The text was updated successfully, but these errors were encountered: