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

Generate unified Python/C++ docs #1324

Merged
merged 22 commits into from
Nov 2, 2023

Conversation

vyasr
Copy link
Contributor

@vyasr vyasr commented Aug 10, 2023

Description

This PR leverages Breathe to pull the rmm C++ API documentation into the python Sphinx docs build, generating a single unified build of the documentation that supports cross-linking between language libraries and also simplifies cross-linking from other libraries that wish to link here (such as higher-level RAPIDS libraries that use both rmm's Python and C++ APIs).

Using Breathe requires changing the doxygen build to generate XML in addition to the usual HTML. It turns out that doxygen catches more doc issues (of the types fixed in #1317) when more build outputs are turned on, which is indicative of some bugs/limitations in doxygen, but nonetheless I've fixed the additional issues in this PR as well.

Checklist

  • I am familiar with the Contributing Guidelines.
  • New or existing tests cover these changes.
  • The documentation is up to date with these changes.

@vyasr vyasr added feature request New feature or request non-breaking Non-breaking change labels Aug 10, 2023
@vyasr vyasr self-assigned this Aug 10, 2023
@github-actions github-actions bot added Python Related to RMM Python API conda cpp Pertains to C++ code labels Aug 10, 2023
@@ -55,7 +55,7 @@ using failure_callback_t = std::function<bool(std::size_t, void*)>;
* When implementing a callback function for allocation retry, care must be taken to avoid an
* infinite loop. The following example makes sure to only retry the allocation once:
*
* @code{c++}
* @code{.cpp}
Copy link
Member

Choose a reason for hiding this comment

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

Does it work to just leave off the {.cpp}? By default, Doxygen uses the language of the file the @code is found in. Will that work for the unified case?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Unfortunately doxygen-generated XML does not correctly identify hpp files as C++ files. It does work for cpp files, but since rmm's files are all headers I needed to specify this. I do wonder if updating to a newer version of doxygen would improve the situation, and I may test that. I think #1317 needs merging before an y PR to update doxygen, so if the test is promising I'll sequence that work appropriately.

Copy link
Member

Choose a reason for hiding this comment

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

Try modifying the Doxyfile EXTENSION_MAPPING setting?

EXTENSION_MAPPING      = cu=C++ \
                         cuh=C++ \
                         hpp=C++

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That doesn't seem to work, but I'm not sure why. Oddly, specifying @code{.hpp} works (whether or not hpp is added to the EXTENSION_MAPPING), but the default inference of just @code doesn't.

@vyasr vyasr marked this pull request as ready for review September 20, 2023 23:49
@vyasr vyasr requested review from a team as code owners September 20, 2023 23:49
@vyasr vyasr requested review from wence- and bdice September 20, 2023 23:49
python/docs/Makefile Outdated Show resolved Hide resolved
Copy link
Member

@harrism harrism 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 start, but I think this PR is mostly tackling the mechanics of getting RMM Python and C++ APIs unified.

I think the main thing to review here is the generated docs. The RMM C++ API reference is here (requires NVIDIA VPN):
https://downloads.rapids.ai/ci/rmm/pull-request/1324/61abbbc/docs/rmm/html/librmm_api/

I find that very hard to scroll through and read, and there's no table of contents or other useful organization / navigation. It's a wall of (somewhat tiny) text, with very little formatting, font sizes, or HRs to break it up. Also, the order is weird. Ideally this would be broken up conceptually into separate pages about Memory Resources, Containers, Execution Policies, and other concepts. Can we do that with doxygen groups and pages?

Also, there is no differentiation in the TOC to the left between the Python and C++ API References. They both are named "API Reference" (same in the main page here: https://downloads.rapids.ai/ci/rmm/pull-request/1324/61abbbc/docs/rmm/html/)

Also, the page "https://downloads.rapids.ai/ci/rmm/pull-request/1324/61abbbc/docs/rmm/html/basics/" is only about Python, but gets prominent placement as the very first thing. If we are going to unify docs, I think we should give C++ and Python equal footing, like we do in the RMM README.md (which is pretty comprehensive).

I definitely like the idea of integrating the docs, but I think it needs quite a bit of thought and work (and I'm happy to help more).

dependencies.yaml Show resolved Hide resolved
include/rmm/mr/device/logging_resource_adaptor.hpp Outdated Show resolved Hide resolved
include/rmm/mr/device/logging_resource_adaptor.hpp Outdated Show resolved Hide resolved
python/docs/conf.py Outdated Show resolved Hide resolved
python/docs/librmm_api.rst Outdated Show resolved Hide resolved
@vyasr
Copy link
Contributor Author

vyasr commented Sep 21, 2023

@harrism you beat me to the punch, time zones are tricky 😄 I had intended to start exactly that conversation during the US workday today. I've kicked that off on Slack, where we can discuss some of these ideas more before coming to any final conclusions here. I completely agree that the current layout is insufficient and we need to do more work.

@vyasr vyasr mentioned this pull request Sep 25, 2023
3 tasks
@vyasr
Copy link
Contributor Author

vyasr commented Sep 25, 2023

I've split out the doxygen fixes uncovered by enabling XML builds into #1348. I'll make a separate PR adding doxygen groups. Once both of those are merged we can revisit this PR using those groupings.

rapids-bot bot pushed a commit that referenced this pull request Sep 25, 2023
doxygen catches more doc issues (of the types fixed in #1317) when more build outputs are turned on, which is indicative of some bugs/limitations in doxygen. XML builds will be necessary to leverage Breathe (see #1324) so this PR enables XML builds and fixes the associated issues.

Authors:
  - Vyas Ramasubramani (https://github.com/vyasr)

Approvers:
  - Rong Ou (https://github.com/rongou)

URL: #1348
@vyasr vyasr mentioned this pull request Oct 11, 2023
3 tasks
rapids-bot bot pushed a commit that referenced this pull request Oct 12, 2023
This PR adds doxygen groups for the various parts of the C++ API to help provide more context. This will also help with improving the docs experience in #1324.

Authors:
  - Vyas Ramasubramani (https://github.com/vyasr)

Approvers:
  - Mark Harris (https://github.com/harrism)

URL: #1358
@vyasr vyasr requested a review from a team as a code owner October 25, 2023 17:50
@vyasr vyasr changed the base branch from branch-23.10 to branch-23.12 October 25, 2023 17:51
@github-actions github-actions bot removed the CMake label Oct 25, 2023
@vyasr
Copy link
Contributor Author

vyasr commented Oct 27, 2023

In the following image you can see "Detailed Description" at the bottom of the page with nothing after it. Every page seems to have this. Can we suppress it?

(This should probably be for a follow up PR) I would like each of the groups to have some summary text at the top of the page explaining what the group contains with definitions and usage overview

All of libcudf's docs have the same issue. I just opened rapidsai/cudf#14341 to remove the extra section. However, that's the section where you would include the summary text that you want I think. So it sounds like what you'd prefer is to instead create a DoxygenLayout file in rmm and move the detailed description for the group to the top of the page. Those are our options, either we remove that section or we fill it in for each group. WDYT? Also feel free to comment on the cudf PR since I assume we'll want similar solutions for both repos.

This image shows the modules are sorted alphabetically. I think they should be sorted by "importance", or by logical order of introducing concepts. E.g. I think Memory Resources and Data Containers should be first, since that's what people will use most.

We control the order, I just alphabetized by default. Please propose an ordering! I'm happy to go with what you think makes sense.

Also you can see namespace rmm making an appearance on this page without explanation. This seems out of place.

That's coming from this line. I included that because everywhere in the docs where there is anything within the rmm namespace Sphinx tries to create a link, so without this Sphinx throws warnings about missing references. We have three options here:

  1. Leave this empty namespace doc as is.
  2. Find something useful to include along with this namespace doc.
  3. Remove it and find a way to suppress a warning

I'm guessing you prefer 2 or 3, WDYT?

This image highlights one of my common issues with Python documentation sites. ...

I'd prefer to address this in a follow-up PR. The best ways to fix it would involve using an alternate theme for the documentation, but switching themes will affect more than just the C++ documentation and could involve other changes. I'd prefer to merge this PR largely as is since it makes the Sphinx C++ documentation no worse than the existing Sphinx Python documentation, then come back to improving the overall formatting in a follow-up PR that affects the entire Sphinx docs. In all likelihood this will involve something like https://github.com/rapidsai/sphinx-theme/.

There seems to be something wrong with this logging page. This must be the documentation for a function?

This was caused by the same issue you noticed in the doxygen docs, a mistake in the doxygen. I've fixed that now.

The search page is empty...

In Sphinx the Search page is empty until you actually perform a search for something

Clicking on "Module Index" under "librmm documentation" (which should be C++) takes me to the "Python Module Index" page, which probably doesn't need to be grouped by letter of the alphabet since it only has one letter. :)

Turns out the module index is specifically designed for Python, so I'll just remove that here. That's an autogenerated page, so not sure how much control we have over it, but if we can modify it I'd say that's a task for a follow-up PR since it's not specific to the unification here.

If I navigate to "Index" under "Indices and Tables", it collapses the TOC on the left so I can't see where I am. In general the TOC doesn't seem to have as many levels as it should, so I can't always tell where I am.

I agree that we should improve this, but I see similar issues even at the very top level of the documentation so I don't think it's something we should address in this PR. Let's do that in a follow-up to improve the docs overall.

Copy link
Member

@harrism harrism left a comment

Choose a reason for hiding this comment

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

Here's what I suggest for the ordering.

python/docs/librmm_docs/index.rst Outdated Show resolved Hide resolved
@harrism
Copy link
Member

harrism commented Oct 31, 2023

group to the top of the page. Those are our options, either we remove that section or we fill it in for each group. WDYT?

I think we should fill it in for each group and move it under the title for the page. We can do that in a followup.

We control the order, I just alphabetized by default. Please propose an ordering! I'm happy to go with what you think makes sense.

Done.

We have three options here:

1. Leave this empty namespace doc as is.

2. Find something useful to include along with this namespace doc.

3. Remove it and find a way to suppress a warning

I think (2). I always err on the side of more documentation. :)

Turns out the module index is specifically designed for Python, so I'll just remove that here.

Yes please.

@vyasr
Copy link
Contributor Author

vyasr commented Oct 31, 2023

I think (2). I always err on the side of more documentation. :)

Since that's focusing on content, let's do that in a follow-up PR where we also add documentation for the groups.

@harrism
Copy link
Member

harrism commented Oct 31, 2023

I think (2). I always err on the side of more documentation. :)

Since that's focusing on content, let's do that in a follow-up PR where we also add documentation for the groups.

Agree with all the followups, but can you file an issue with a checklist to capture them all? (can convert the checklist items to individual issues if needed).

@vyasr
Copy link
Contributor Author

vyasr commented Oct 31, 2023

Yup, opened #1368.

@vyasr vyasr requested a review from bdice November 1, 2023 00:44
Copy link
Contributor

@bdice bdice left a comment

Choose a reason for hiding this comment

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

I have a few related comments on organization. This is such a dramatic improvement that I'm approving and want to ship it. I would support doing all further work in separate PRs.

Comment on lines +1 to +2
Welcome to the rmm C++ documentation!
========================================
Copy link
Contributor

Choose a reason for hiding this comment

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

This shows up in the navigation bar (they call these "breadcrumbs").

image

I would prefer to do something like:

Suggested change
Welcome to the rmm C++ documentation!
========================================
rmm C++
=======

Copy link
Member

Choose a reason for hiding this comment

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

I agree -- never liked the "Welcome to" prefix on practically every Python package's docs.

Comment on lines +6 to +7
librmm Documentation
====================
Copy link
Contributor

Choose a reason for hiding this comment

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

This heading makes the breadcrumbs deeply nested. The navigation is awkward as a result.

image

Can we eliminate this level of the hierarchy entirely, so that it's something more like Home / rmm C++ / API Reference / Memory Resources? See if you can fuse this page's toctree into python/docs/cpp.rst instead.

Comment on lines +1 to +2
Welcome to the rmm Python documentation!
========================================
Copy link
Contributor

Choose a reason for hiding this comment

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

As above, this makes for an awkward breadcrumb.

image

Suggested change
Welcome to the rmm Python documentation!
========================================
rmm Python
==========

Copy link
Member

@ajschmidt8 ajschmidt8 left a comment

Choose a reason for hiding this comment

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

Looks good to me.

Seems like we no longer need to generate/upload separate librmm HTML docs, right?

If that's correct, then we should remove the lines below from build_docs.sh:

https://github.com/vyasr/rmm/blob/9e81c7303816ef53419e8754e9dc5416044eea56/ci/build_docs.sh#L34-L35

Additionally, we'll want to set nightly: 0 in the file below on our documentation site:

@vyasr
Copy link
Contributor Author

vyasr commented Nov 2, 2023

/merge

@rapids-bot rapids-bot bot merged commit f4afa6a into rapidsai:branch-23.12 Nov 2, 2023
44 checks passed
@vyasr vyasr deleted the feat/unify_docs branch November 2, 2023 23:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
conda cpp Pertains to C++ code feature request New feature or request non-breaking Non-breaking change Python Related to RMM Python API
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

4 participants