Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Broken links in docs #138

Open
jl-wynen opened this issue Dec 2, 2024 · 1 comment
Open

Broken links in docs #138

jl-wynen opened this issue Dec 2, 2024 · 1 comment
Labels
documentation Improvements or additions to documentation

Comments

@jl-wynen jl-wynen added the documentation Improvements or additions to documentation label Dec 2, 2024
@jl-wynen jl-wynen moved this from Triage to Selected in Development Board Dec 2, 2024
@jl-wynen jl-wynen self-assigned this Dec 12, 2024
@jl-wynen jl-wynen moved this from Selected to In progress in Development Board Dec 12, 2024
@jl-wynen
Copy link
Member Author

I don't see a simple solution to

One of the is tricky, it looks like Sphinx pulled in the docstring of scipp.Variable for a domain type. And that docstring has a relative link to a page in the Scipp docs.

The problem is larger than this. The generated pages for generic domain types (subclasses of sciline.Scope) are pretty bad:
Screenshot_20241212_120211
They don't show the base classes but contain a line like DetectorPositionOffset(x: SUPER) which is based on Scope.__new__. It shows SUPER, a TypeVar used by Scope that is not very meaningful in the docs.
In addition, they show the base class' __init__ as well as a list of base class methods. The latter is fine, but the __init__ is not great because we normally don't initialise domain types like this. We use something like DetectorPositionOffset(var) instead.

There are several potential solutions:

  • Use a custom class template instead of docs/_templates/class-template.rst. This could produce decent output but it would be difficult to identify base classes in the template. Plus we would need a way to switch to it in place of the default template, but only for domain types.
  • Use a custom module template for the types module(s). Same as above, we would need a way to make Sphinx use that instead of the default one. But this may be easier.
  • Implement a Sphinx plugin. I tried it briefly but I could not find a good hook where we could customise classes before they are processed by autosummary.

@jl-wynen jl-wynen mentioned this issue Dec 12, 2024
@jl-wynen jl-wynen removed their assignment Dec 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
Status: In progress
Development

No branches or pull requests

1 participant