init: frontmatter support

[hsjobeki]

Add support for frontmatter

Why frontmatter is needed (sometimes)

Sometimes it is desireable to extend the content with meta information. Frontmatter is the de-facto standard of adding document specific meta tags to markdown. 1 2 3

This would allow us to keep track of references between documents that are closely related to nix code or externalized doc-comments that are no longer tracked.

This PR also includes a detailed design document.

i.e.,

• Enriching documentation generation.
• Maintaining References.
• Metadata inclusion.
• Allow better Handling of edge cases.

Example

{
/** 
 ---
 import: ./path.md
 ---
*/
foo = x: x;
}

TODO

• [x] Unit tests
• [x] Bump version
• [x] Manual testing with nixpkgs/nixos manuals

[nixos-discourse]

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

https://discourse.nixos.org/t/2024-03-21-documentation-team-meeting-notes-114/41957/1

[hsjobeki]

@infinisil I think this PR is ready from my side. If you could give it a quick revise, if all issues are addressed.

Just tested it against nixpkgs with some lib functions. works really nice, didn't notice any problems or issues with the other tooling whatsoever.

Note: I switched to another frontmatter parser library because the error handling wasn't expressive enough.

[fricklerhandwerk]

Reviewed in the docs team meeting:

• We've discussed this quite intensely, because I have strong doubts this is not an anti-pattern in the long run
• The motivation as stated is a bit weak; the only concrete problems it would solve are:
  • Editing large doc strings has better tooling support in plain markdown files
  • Avoiding large doc strings in the source makes the code slightly easier to navigate
• On the other hand:
  • It adds a layer of indirection ('invisible behavior' you have to "kinda know it exists"), e.g. what exactly does doc-location mean?
  • You need to navigate and edit multiple files if the pattern is used
  • I say: When the pattern is used, it's proliferated over time, and I fear it will add friction below the threshold of pain. So it won't get reported to actually get mitigation.
• This is a trade-off, and there's no obviously correct solution
• Agreement: Postpone merging until we have a clear-cut use case that would be to painful to support without this feature

(PS: @hsjobeki and @DanielSidhion your effort to improve reference documentation overall is highly laudable, so my critique of this particular pattern is not to dismiss your work.)

[hsjobeki]

When the pattern is used, it's proliferated over time, and I fear it will add friction below the threshold of pain.

@fricklerhandwerk @infinisil.

This fear is justified, and I share it. Nevertheless, it would be very beneficial to provide this feature for individual edge cases with very long documentation. This should not be used extensively, and there are only a handful of places where I can imagine this. For example, the "mkDerivation" function documentation is rather extensive, and you wouldn't want that in the source code.

So nixdoc is just a documentation tool that offers this feature. It is not an official tool or an opinionated tool. But nixpkgs should adhere to usage guidelines. e.g. to use the doc_location feature only for certain functions.

I am still demanding this feature and planning to add more features to "frontmatter" later on, which might be needed in my vision for improved documentation.

But i am okay to let this PR stay open until we really need it. (e.g. when we can generate documentation for mkDerviation)

[nixos-discourse]

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

https://discourse.nixos.org/t/2024-03-28-documentation-team-meeting-notes-115/42329/1