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

Vacation PR: multi-paged, styled, searchable docs with wrapper tooling and epubs for NixOS and Nixpkgs #68020

Closed
wants to merge 81 commits into from

Conversation

grahamc
Copy link
Member

@grahamc grahamc commented Sep 3, 2019

TLDR:

Motivation for this change
  • The generated doc pages are huge and don't get indexed.
  • Ctrl-F is a decent search tool, but a proper search engine with stemming is better.
  • Smaller pages are easier to navigate.
  • The output of nix-build was boring.
Things done
  1. Introduce a docbook-index tool for indexing DocBook against the generated HTML.
  2. Split up the outputted documentation in to many smaller pages.
  3. Added a whole new layout and theme to the docs which is consistent across NixOS and Nixpkgs.
  4. Added a local, in-browser search engine (Elasticlunr, what Rust uses.)
  5. Way reduced the complexity of generating the Nixpkgs and NixOS docs.
  6. Made the Nixpkgs and NixOS docs build the same way.
  7. Created nix-doc-tools, a metapackage used for building our documentation.
  8. Updated the how to write docs for nixos docs to account for the nix-doc-tools tooling updates.

BTW: nixpkgs and nixos docs are built the same way, so the docs apply to both.

Major thanks to @samueldr for the work on this.

  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

NOT DONE:

  • Determined the impact on package closure size (by running nix path-info -S before and after)
    Need to determine the impact of building these docs on the minimal ISO.

I'm going on vacation, so I'll be back on the 16th or so to see what y'all think.

btw, samueldr can make fixes to this branch for style/js things :)

@jonringer
Copy link
Contributor

manpages no longer exists on manual attr set:

++ optional cfg.man.enable manual.manpages

I only see manual, manualHTML, manualHTMLShell

@veprbl
Copy link
Member

veprbl commented Sep 3, 2019

Will this break all of the current URLs that refer to the anchors on the single page?

@samueldr
Copy link
Member

samueldr commented Sep 4, 2019

Will this break all of the current URLs that refer to the anchors on the single page?

Yes, as it is. I think we could work out a solution, literally thinking of it as I type.

  1. Prepare an index of anchors (they should still be named the same)
  2. On index.html, at load, cross-reference anchor with index, redirect.

The main issue there could be is history hijacking. It may be possible to do something tricky with html5 history, and window.reload, to overwrite the one entry.

Tasks
  • Implement JS for redirection on index
  • Implement anchors index

@davidak
Copy link
Member

davidak commented Sep 4, 2019

Great work!

Can we have the search box in the header like this?

Screenshot from 2019-09-04 18-38-28

@samueldr
Copy link
Member

samueldr commented Sep 4, 2019

It might be possible, but it will cause issues with narrower layouts, especially with sections having longer titles.

There is another issue with the UX where the current implementation presents a clear separation of the search mode and the documentation consultation mode.

And additionally, while it looks like there is only a search box, there are elements in the search overlay that are currently unlikely to be seen. Among those is the loading state of the index. If we want to add more options to the search engine we would be furthermore constrained in space.

So, the short of it is that horizontal space is a premium, and it can't easily be spared for the search box. I did initially try it in the header, but it didn't feel right.

@grahamc
Copy link
Member Author

grahamc commented Sep 9, 2019

materializes from vacation for a few minutes hmm not a lot of feedback ❤️ . I hope this can get in for 19.09! :) disappears back to vacation

@toonn
Copy link
Contributor

toonn commented Sep 9, 2019

Some feedback from someone who uses a narrow (for today's standards) browser. The index takes up a lot of horizontal space when you're not using it. The python docs handle this really well by allowing you to fold the index.

Another thing that has always kinda annoyed me, the toc is super long (multiple accelerated scrolls long), and beginners have no need for it. The main page imo should either be the first section or a short explanation of the important bits of the manual, describing what's in the nixpkgs manual and that other manuals exist, e.g., nix and nixos manuals respectively and why they might want to read those instead (similar treatment for the other manuals).

@samueldr
Copy link
Member

samueldr commented Sep 9, 2019

Some feedback from someone who uses a narrow (for today's standards) browser. The index takes up a lot of horizontal space when you're not using it. The python docs handle this really well by allowing you to fold the index.

I guess you're not going narrow enough :)

image

I do use a narrow column, often, and have chosen what felt like an appropriate breakpoint to put the menu away. Though, I do agree that (maybe as a later step) a control could be added to toggle the menu at any levels.

Tasks
  • Index collapse/open control

Copy link
Contributor

@jtojnar jtojnar left a comment

Choose a reason for hiding this comment

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

Big 👍 for fixing #68199 even before I opened it.

The tools look great, the only pain point is that docs-build is somewhat slower than make out/html/index.html. Maybe it would make sense to split the HTML and EPUB builds. I dream of fast rebuilds with live reloading the HTML page but I doubt there are free XSLT processors that support incremental builds.

@@ -189,7 +187,7 @@
desired outputs or it moves the files during the fixup phase. Each group of
file types has an <varname>outputFoo</varname> variable specifying the
output name where they should go. If that variable isn't defined by the
derivation writer, it is guessed &ndash; a default output name is defined,
derivation writer, it is guessed &#x2013; a default output name is defined,
Copy link
Contributor

Choose a reason for hiding this comment

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

I like to use it too. That’s why I have Compose key enabled:

Suggested change
derivation writer, it is guessed &#x2013; a default output name is defined,
derivation writer, it is guessed a default output name is defined,

xmlns:d="http://docbook.org/ns/docbook"
version="1.0">
<!--
`ul` option puts the `ul` underneat the parent's `li`, whereas `dd` and `dt` (default)
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
`ul` option puts the `ul` underneat the parent's `li`, whereas `dd` and `dt` (default)
`ul` option puts the `ul` underneath the parents `li`, whereas `dd` and `dt` (default)

pkgs/tools/misc/nix-doc-tools/default.nix Outdated Show resolved Hide resolved
pkgs/tools/misc/nix-doc-tools/lib.nix Outdated Show resolved Hide resolved
pkgs/tools/misc/nix-doc-tools/search.js Outdated Show resolved Hide resolved
pkgs/tools/misc/nix-doc-tools/parameters.xsl Show resolved Hide resolved
pkgs/tools/misc/nix-doc-tools/default.nix Show resolved Hide resolved
@@ -16,6 +17,14 @@ let
paths = [ doclib.standard-tools ] ++ generated-files;
};

# a `docs-generate` command special for a nix-shell, since it
# uses `nix-build` instead of hard-coding a path.
Copy link
Contributor

Choose a reason for hiding this comment

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

What does this mean? Where does it use nix-build?

sources = lib.sourceFilesBySuffices ./. [".nix" ".xml"];

modulesDoc = builtins.toFile "modules.xml" ''
<section xmlns:xi="http://www.w3.org/2001/XInclude" id="modules">
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
<section xmlns:xi="http://www.w3.org/2001/XInclude" id="modules">
<section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude" id="modules">

got generated. The HTML will be accessible through the
<filename>result</filename> symlink at
This build will produce a styled and indexed HTML document, and an epub. The
HTML will be accessible through the <filename>result</filename> symlink at
<filename>./result/share/doc/nixos/index.html</filename>.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
<filename>./result/share/doc/nixos/index.html</filename>.
<filename>./result/share/doc/nixos-manual/html/index.html</filename>.

@toonn
Copy link
Contributor

toonn commented Sep 10, 2019

I guess you're not going narrow enough : )

@samueldr apparently it's about a cm's worth of difference. But when you go narrower you lose the index completely? The nice thing about the python docs is that you can choose whether you want the index visible or not and that it's never inaccessible.

@lheckemann lheckemann added this to the 20.03 milestone Sep 10, 2019
@samueldr
Copy link
Member

samueldr commented Sep 14, 2019

I have marked a couple of @jtojnar's suggestions as resolved, they were trivial changes or changes I approve, in this WIP branch.

There are additional changes in there that I would prefer graham would take a look first :)

@samueldr
Copy link
Member

Answering @toonn's question:

But when you go narrower you lose the index completely?

Not at all! There are three ways the narrow view allows the user to navigate:

  • The navigation icons at the top, to move to siblings or parent nodes.
  • The local TOC gets expanded at the top of the content, for easy visualization of the parent nodes, and the document's nodes.
  • The full TOC is present at the end of the document.

In fact, the narrow view shows more to the user, compared to the full view. Though, in reality the additional navigation at the end of the page is not as trivial to use.

The nice thing about the python docs is that you can choose whether you want the index visible or not and that it's never inaccessible.

And you're right, it's nice to have the option to toggle it :).

@samueldr
Copy link
Member

samueldr commented Sep 15, 2019

cc: @toonn

https://stuff.samueldr.com/nixpkgs/manual/

  • ✔️ That version has the togglable TOC.
  • ✔️ That version has redirection.

To test the redirection:

Both index.html and index.html-less versions should redirect to the right location. That is because both index.html and index.html-less versions of the page are served by the nixos.org server.

I made sure to host the page at a location mimicking the URL structure from nixos.org.

@toonn
Copy link
Contributor

toonn commented Sep 15, 2019

@samueldr, very nice. All I'm missing is a friendlier "main" page than a detailed TOC like I mentioned earlier and possibly having toggles in the sidebar to open up items and dig down to sub sections. But this is already a major improvement imo. 👍

@samueldr
Copy link
Member

All I'm missing is a friendlier "main" page

This is out of scope of the PR; contents (except contribution to the documentation) is not part of this PR, considering this reviews the way docs function, both building and using documentation. Though I agree that this is a desirable improvement, to have something more on the main page.

[...] having toggles in the sidebar to open up items and dig down to sub sections.

It was tried, but does not work well. Every level of the documentation has a page it links to. This meant that a control only used to toggle the open state of a section in the TOC would have to be implemented. Instead, I deemed it was more user-friendly to simply have one action for the options in the menu "follow and expand". With a local file, the navigation is instant, meaning there is no drawback. With hosted files (e.g. nixos.org) the navigation is near instant, due to the major decrease in page size. The cost in maintaining an additional non-native feature to the documentation is imho not worth the ability the collapse/expand TOC sections at will. That is especially true considering that following a link loses the expanded/collapsed state.

@toonn
Copy link
Contributor

toonn commented Sep 16, 2019

Then perhaps a static extra level to the TOC? The current sections are too broad imo, making the sidebar less useful.


functions/library/generated: doc-support/result
ln -rfs ./doc-support/result/function-docs functions/library/generated
all: ${MD_TARGETS}

%.section.xml: %.section.md
pandoc $^ -w docbook+smart \
Copy link
Contributor

Choose a reason for hiding this comment

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

According to the manual pandoc does not support smart extension for docbook.

https://pandoc.org/MANUAL#typography

@grahamc grahamc requested a review from nbp as a code owner September 18, 2019 23:56
samueldr and others added 9 commits September 18, 2019 21:27
What's the deal with the `cd`??

The filename used in the index are relative to cwd/the given path. This
means that to produce the expected filename associations, we need to be
in the right directory when producing the index.

Alternatively, the indexing tool could have been made to strip the
leading path from the filenames.
They were always a separate build anyway, but this way it is easier to
tell.
Allows for cross-referencing documentation. The way
this is built, nixpkgs can depend on nixos, nixos can
depend on nixpkgs, without an infinite loop.
@grahamc
Copy link
Member Author

grahamc commented Sep 19, 2019

  • <xsl:template name="make.toc"> is way too slow right now. Disabled for development, but needs to be re-enabled so the ToCs work properly.

@Mic92
Copy link
Member

Mic92 commented Jan 13, 2020

@grahamc is it known why xslt is too slow. Could be there a switch that only generates the expensive variant for nixos.org and not for local use?

@disassembler disassembler modified the milestones: 20.03, 20.09 Feb 5, 2020
@nixos-discourse
Copy link

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/documentation-presentation-navigation/6401/3

@Mic92
Copy link
Member

Mic92 commented May 28, 2020

Should we close this PR?

@jonringer
Copy link
Contributor

It does have a large number of conflicts. And not sure what direction the docs are going after the recent rfc and marketing team changes

cc @garbas

@grahamc grahamc closed this May 28, 2020
@jonringer
Copy link
Contributor

@grahamc your time and effort is still appreciated. Thank you for your hard work :)

@grahamc
Copy link
Member Author

grahamc commented May 29, 2020 via email

@nixos-discourse
Copy link

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/any-consensus-on-documentation-generation-tool-for-nixpkgs-manual/15550/2

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

Successfully merging this pull request may close these issues.

None yet