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

Sphinx Python Documentation #1567

Draft
wants to merge 55 commits into
base: main
Choose a base branch
from

Conversation

StefanHabel
Copy link
Contributor

@StefanHabel StefanHabel commented Oct 13, 2023

Work in progress.

This PR adds a new build target named MaterialXDocsPython, which generates Python API documentation using Sphinx.

The existing developer guide contents are incorporated into the new HTML documentation, which lives side-by-side to the existing Doxygen-generated C++ API documentation.

Docstrings were added to all modules, functions, classes, methods, and attributes.

All parameters were named. None should appear as arg0, arg1, arg2 etc anymore.

Statistics about the Python API have been added to the Sphinx build process.

The Sphinx build output currently ends with the following messages, providing an overview of the state of the API docs:

The MaterialX Python API consists of:
    * 11 modules
    * 48 functions
    * 139 classes
    * 1180 methods
    * 6 exception types

build succeeded.

Docstring example:

$ python3 -c 'import PyMaterialXFormat; help(PyMaterialXFormat.flattenFilenames)'
Help on built-in function flattenFilenames in module PyMaterialXFormat:

flattenFilenames(...) method of builtins.PyCapsule instance
    flattenFilenames(doc: PyMaterialXCore.Document, searchPath: PyMaterialXFormat.FileSearchPath = mx.FileSearchPath(), customResolver: PyMaterialXCore.StringResolver = None) -> None

    Flatten all filenames in the given document, applying string resolvers at
    the scope of each element and removing all fileprefix attributes.

    :param doc: The document to modify.
    :type doc: Document
    :param searchPath: An optional search path for relative to absolute path
        conversion.
    :type searchPath: FileSearchPath
    :param customResolver: An optional custom resolver to apply.
    :type customResolver: StringResolver

Preview of generated HTML pages:

Screenshot 2023-10-21 at 14 14 41
Screenshot 2023-10-21 at 14 28 03

Development environment:

  • Apple clang version 15.0.0 (clang-1500.0.40.1)
  • Python 3.12.0 (v3.12.0:0fb18b02c8, Oct 2 2023, 09:45:56) [Clang 13.0.0 (clang-1300.0.29.30)] on darwin
  • Sphinx 7.2.6
  • cmake version 3.27.6

Update #342

@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Oct 13, 2023

CLA Signed

The committers listed above are authorized under a signed CLA.

@StefanHabel StefanHabel marked this pull request as draft October 13, 2023 01:46
Copy link
Contributor

@kwokcb kwokcb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a great addition to have !
I left some minor niggly comments. The only real question I had is any inter-dependence on building the actual Python modules.
Thanks.

documents/DeveloperGuide/ShaderGeneration.md Outdated Show resolved Hide resolved
documents/DeveloperGuide/index.rst Outdated Show resolved Hide resolved
documents/sphinx-custom.css Show resolved Hide resolved
documents/CMakeLists.txt Show resolved Hide resolved
### Example Images
## Example Images

![MaterialX Graph Editor with procedural marble example](../Images/MaterialXGraphEditor_Marble.png)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not specific to this PR but I noticed that images don't show up properly on the PyPi package page for MaterialX.
If were adding more images, just curious is there a more robust way to specify image references -- such as an absolute reference to the web site location instead of using relative paths ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I see the issue: https://pypi.org/project/materialx/

It's great to see that the documentation content is reused in many places!

I've migrated the Markdown docs, including README.md, to use absolute paths now:

@jstone-lucasfilm jstone-lucasfilm changed the title Update #342 Sphinx Python Documentation. Sphinx Python Documentation Oct 13, 2023
@StefanHabel StefanHabel force-pushed the #342-Sphinx-Python-Documentation branch from 8a66335 to 9e4c1ff Compare October 16, 2023 04:54
Work in progress.

This PR adds a new build target named `MaterialXDocsPython`,
which generates Python API documentation using Sphinx.

The existing developer guide contents are incorporated into
the new HTML documentation, which lives side-by-side to the
existing Doxygen-generated C++ API documentation.

The docstrings of the Python modules were tweaked to describe
what the individual modules are responsible for.

Signed-off-by: Stefan Habel <[email protected]>
@StefanHabel StefanHabel force-pushed the #342-Sphinx-Python-Documentation branch from 9e4c1ff to bef6e1f Compare October 18, 2023 05:46
…d Markdown files to use absolute URLs.

This is to make sure the URLs can be loaded within GitHub, Doxygen,
Sphinx, and the PyPI project page. Requires internet access.

Also updated XML text snippets to use XML comment delimiters.
…d `index.rst`.

Changed index page title, added introduction text, and changed the
order of Python modules, to reflect the order in which support for the
different shading languages was added to MaterialX.
…ed import order dependency issue.

This patch adds calls of `pybind11::module::import()` to the Python
bindings of modules that depend on specific other modules.

This approach is similar to importing required modules via `import` in
Python packages/modules.

At the same time, we can remove the new documentation for this issue,
and can remove extra steps from the Sphinx `conf.py` configuration file.

With this patch in place, it should be possible to import any of the
MaterialX Python modules in any order.
…d Sphinx configuration.

- Added a new description/about text in the sidebar, including blue
  link buttons to GitHub and MaterialX on Mastodon (with an SVG-based
  embedded icon)
- Applied the "monokai" syntax highlighting theme to code snippets
- Added custom Jinja templates for classes and modules, in order to add
  a section title before the alphabetical indices on pages
- Added a custom HTML template for the navigation section in the sidebar
  in order to limit the depth of the table of contents
- Added code to remove module names from the signatures of functions,
  in order to make the docs more readable
…define to produce detailed error messages in pybind11.
…d aliasing of `PyMaterialXFormat.readFromXmlFile()` function.

The function is now exposed under its real name in the pybind11 bindings
in C++.
either within the `MaterialX` Python package or as a standalone module.

Signed-off-by: Stefan Habel <[email protected]>
@@ -19,7 +19,7 @@ MATERIALX_NAMESPACE_BEGIN
/// filtered by the given shader type and target. By default, all surface shader nodes
/// are returned.
/// @param materialNode The node to examine.
/// @param nodeType THe shader node type to return. Defaults to the surface shader type.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@StefanHabel Starting with this edit, I'm seeing a great set of fixes to spelling, letter case, and other details in the C++ libraries for MaterialX. Would it make sense to separate these out into their own pull request, so that they can be reviewed independently of the new Python Documentation functionality in this proposal?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, thanks @jstone-lucasfilm !

This PR is getting a little unwieldy.

We could generally split this into separate PRs:

  1. Base functionality of generating the Python API Documentation via Sphinx.
  2. Fixes in header files for typos encountered while copying docs in headers to docstrings in the Python bindings.
  3. Added argument names and docstrings in the Python bindings.

We could treat this PR here (1567) as the one for the Sphinx base functionality, splitting off parts 2 and 3 into separate PRs.

The third part (adding the actual docstrings) could be broken apart further into four separate PRs for the main (groups of) MaterialX Python modules:

  • PyMaterialXCore
  • PyMaterialXFormat
  • PyMaterialXGenShader
    • PyMaterialXGenGlsl
    • PyMaterialXGenOsl
    • PyMaterialXGenMdl
    • PyMaterialXGenMsl
  • PyMaterialXRender
    • PyMaterialXRenderGlsl
    • PyMaterialXRenderOsl
    • PyMaterialXRenderMsl

While working on this, I also encountered a couple of issues in the bindings themselves:

We could treat these issues in the Python bindings as a separate ticket and PR.

Here's a list of tickets and corresponding PRs in which we could organize the overall work here:

  • New issue ticket for existing issues in Python bindings
    • New PR to address the issues
  • Sphinx Python Documentation #342
    • Sphinx Python Documentation #1567 for the Sphinx part
    • Separate new PR for docstrings for PyMaterialXCore
    • Separate new PR for docstrings for PyMaterialXFormat
    • Separate new PR for docstrings for PyMaterialXGen{Shader,Glsl,Osl,Mdl,Msl}
    • Separate new PR for docstrings for PyMaterialXRender{,Glsl,Osl,Msl}
    • Separate new PR for fixes in header files

Alternatively:

I'd be happy with either approach.

I have more commits to add to this PR here, adding more argument names and docstrings. I'll keeping using this PR here for this for now.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@StefanHabel One approach that could be useful here is to break out one separable change at a time from this larger pull request (e.g. fixes to C++ libraries), so that it can be reviewed and merged to MaterialX main on its own.

As each of these subsets is reviewed and merged to main, we can then click "Update Branch" on this larger pull request, effectively removing that subset from the main proposal.

This should help to focus reviewer attention on a single, independent change at a time, rather than considering the entire proposal at once.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Understood! Sounds good!

I'll upload a few more commits to this PR here, to have everything in one place.

I'll then create separate PRs for subsets of this work, which can be reviewed and merged independently.

…ademySoftwareFoundation#1567)

Mentioning that all functions and classes from those modules are available
in the top-level `MaterialX` Python package.

Also removed the repeated `import` statements from example code in utility
functions of `PyMaterialXCore`.

Also wrapped more module docstrings in `PYMATERIALX_DOCSTRING()`.

Signed-off-by: Stefan Habel <[email protected]>
…Foundation#1567)

...by renaming `Element._getChild()` to `Element.getChild()`.

Signed-off-by: Stefan Habel <[email protected]>
@jstone-lucasfilm
Copy link
Member

@StefanHabel We'll be holding ASWF Dev Days 2024 on September 26th and 27th, so let us know if you might be interested in following up on this project then!

https://www.aswf.io/dev-days-2024/

@StefanHabel
Copy link
Contributor Author

@StefanHabel We'll be holding ASWF Dev Days 2024 on September 26th and 27th, so let us know if you might be interested in following up on this project then!

https://www.aswf.io/dev-days-2024/

Absolutely, count me in!

Apologies for putting this on hold for so long.

Looking forward to it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants