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
In versions of the api reference that used sphinx-apidoc, documentation from private modules were being included via python domain directives. The 2 occurrences of this include:
The above logic works because apidoc executes imports, so it is still able to resolve the location of the documented python objects even though the */gate/ folder is excluded from the api documentation.
Due to switching to autoapi, this logic will not work when using equivalent autoapi directives because autoapi parses files and never executes imports, making it unable to resolve the location of the python objects.
This issue should address the best way forward to solve this problem.
The text was updated successfully, but these errors were encountered:
I think we should move the referenced objects to the core sub-package. The locations HAVE to be documented and available publicly as it is a cornerstone of how DPF works.
As for error, I think error types should be public too and documented as we then would be able to add explanations and examples to their docstrings.
In versions of the api reference that used sphinx-apidoc, documentation from private modules were being included via python domain directives. The 2 occurrences of this include:
The above logic works because apidoc executes imports, so it is still able to resolve the location of the documented python objects even though the */gate/ folder is excluded from the api documentation.
Due to switching to autoapi, this logic will not work when using equivalent autoapi directives because autoapi parses files and never executes imports, making it unable to resolve the location of the python objects.
This issue should address the best way forward to solve this problem.
The text was updated successfully, but these errors were encountered: