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

[RFC 0145] Doc-comments #145

Merged
merged 116 commits into from
Nov 29, 2023
Merged

[RFC 0145] Doc-comments #145

merged 116 commits into from
Nov 29, 2023

Conversation

hsjobeki
Copy link
Contributor

@hsjobeki hsjobeki commented Mar 29, 2023

Find a common sense for doc-comments.

What does a doc-comment look like?

The current Nix language doesn't offer doc comments. There is a vague convention that is not satisfying if you want to build reliable tooling.

See rendered rfc here

Why this matters

Various previous PRs and issues tried of finding a solution to automatic API documentation of nix code.

I think NixOS/nix#1652 is the best approach (yet) which also avoids runtime overhead. Unfortunately the maintainer of this PR couldn't manage to find a solution that satisfies all different opinions within the nix community, and thus it never got merged. I'd like to pick up the discussion on documentation again in this RFC format to find an agreement on a usable doc-comment format that satisfies the important need of having documentation.

This RFC is not going to discuss how to write good documentation, or how to style your code or your comments. It outlines the fundamentals that are necessary to integrate doc-comments into the language. Anything beyond that it out of scope for this RFC.

I also developed noogle. Noogle finds expressions and their documentation with the currently inoffical format for doc-comments. — Attempts to extend the scope to discover automatically and index more parts of nixpkgs failed due to a missing standard doc-comment format.

I'm highly convinced It would be possible to build automatic documentation for code with a standard format. Like in any other major ecosystem (e.g. Rust/C++/Go/Js/...).

Update

With support from one of our POCs in nix. I set-up a demo website for reference documentation. Showing the potential impact of doc-comments

Copy link
Member

@gilice gilice left a comment

Choose a reason for hiding this comment

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

I approve a large part of this, but it looks very hastily written. with some grammatical mistakes and self-contradictions.

I would suggest structural revisions too. Most people will read it top to bottom. Please introduce the basics first (eg that you suggest multiple alternatives) to make the proposal easier to understand.

rfcs/0145-doc-strings.md Outdated Show resolved Hide resolved
rfcs/0145-doc-strings.md Outdated Show resolved Hide resolved
rfcs/0145-doc-strings.md Outdated Show resolved Hide resolved
rfcs/0145-doc-strings.md Outdated Show resolved Hide resolved
rfcs/0145-doc-strings.md Outdated Show resolved Hide resolved
rfcs/0145-doc-strings.md Outdated Show resolved Hide resolved
rfcs/0145-doc-strings.md Outdated Show resolved Hide resolved
rfcs/0145-doc-strings.md Outdated Show resolved Hide resolved
@hsjobeki
Copy link
Contributor Author

hsjobeki commented Mar 29, 2023

art of this, but it looks very hastily written. with some grammatical mistakes and self-contradictions.

Thanks for your feedback. I wanted to include the community at early stage to gather feedback. I'm sorry if it is not cleaned up yet. I'll fix this asap to avoid confusion.

rfcs/0145-doc-strings.md Outdated Show resolved Hide resolved
rfcs/0145-doc-strings.md Outdated Show resolved Hide resolved
rfcs/0145-doc-strings.md Outdated Show resolved Hide resolved
rfcs/0145-doc-strings.md Outdated Show resolved Hide resolved
rfcs/0145-doc-strings.md Outdated Show resolved Hide resolved
@hsjobeki
Copy link
Contributor Author

hsjobeki commented Mar 29, 2023

@figsoda, do you want to be the RFC co-author? I would be delighted if somebody assisted with those efforts.
And you already helped a lot. 👍

@figsoda
Copy link
Member

figsoda commented Mar 29, 2023

@figsoda, do you want to be the RFC co-author?

I don't have the time capacity currently, but I will keep my options open for now

@hsjobeki
Copy link
Contributor Author

hsjobeki commented Mar 30, 2023

I have seen it. But it can take time to adapt to the nix ecosystem.
This could be a tool (??) after we introduce doc-strings. Until now, there are just comments. Even if Doxygen would understand nix, it could see only non-informative internal comments that don't help to lower the entry barrier.
There is no way to syntactically and visually use a comment for doc-strings. If you have any suggestions here, I am happy to hear them. So go ahead and let us hear your criticisms :)

@gilice
Copy link
Member

gilice commented Mar 30, 2023

@AndersonTorres doc generation for nixpkgs has been tried multiple times (also by me).

I am not sure if you are referencing doxygen in a positive, or negative light in this comment.

The main issue with CFG-based doc generators is that

  • nix has multiple forms of comments
  • there isn't a simple function keyword
  • attributes would be also needed to be documented.

In my opinion, a docgenerator will need to parse and possibly evaluate files.

state of the art (SOTA) is currently nixdoc, maintained before by tazjin. As the RFC also states, it is used to generate docs for things in lib

@AndersonTorres
Copy link
Member

I am not sure if you are referencing doxygen in a positive, or negative light in this comment.

Doxygen is the "de facto" standard for doc-comments (I think so). It would be a good starting point - regardless if we decide by not using their tooling.

The main issue with CFG-based doc generators is that

  • nix has multiple forms of comments

The same amount as C++ - /* multiline */ and # single line. Both are supported by Doxygen.

  • there isn't a simple function keyword

Like C (supported by Doxygen)?

  • attributes would be also needed to be documented.

Like @param?

In my opinion, a docgenerator will need to parse and possibly evaluate files.

As I have said in other RFC, it would augment the not-yet-formalized Nixlang.
I think this is too complicated in general, and too complicated to just implement doc-comments in particular.

@hsjobeki
Copy link
Contributor Author

hsjobeki commented Mar 30, 2023

Doxygen is the "de facto" standard for doc-comments (I think so). It would be a good starting point - regardless if we decide by not using their tooling.

Doxygen may inspire the C++ and Java worlds. Although it is a great tool, I think we should extend the existing solution nixdoc

Rust's excellent markdown docstring syntax mainly inspired this RFC.

We should mainly look at Rustdocs' approaches if we want to use markdown similarly.

https://doc.rust-lang.org/rustdoc/how-to-write-documentation.html

(I didn't say not to look into Doxygens ways)

@hsjobeki hsjobeki changed the title init: rfc about docs-string format [RFC 0144] Docstrings Mar 30, 2023
@hsjobeki hsjobeki changed the title [RFC 0144] Docstrings [RFC 0145] Docstrings Mar 30, 2023
@AndersonTorres
Copy link
Member

OK, you are using rustdoc.
I know the Nix RFCs don't mandate/require extra sections, but it would be good to include a last section, "References", including links to the things you are referring to.

@Lassulus
Copy link
Member

so the second FCP has ended again and from reading through the comments I couldn't find any blocking comments. If I'm mistaken and overlooked a comment please tell me. Otherwise I would suggest the steering committee to merge this RFC on the next occasion.

@kevincox
Copy link
Contributor

This RFC is approved!

@kevincox kevincox merged commit c65c832 into NixOS:master Nov 29, 2023
@nixos-discourse
Copy link

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

https://discourse.nixos.org/t/contribute-to-the-nix-2023-recap/37484/3

@nixos-discourse
Copy link

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

https://discourse.nixos.org/t/2024-01-04-documentation-team-meeting-notes-102/37754/1

@Qyriad
Copy link
Member

Qyriad commented Jan 23, 2024

Is there a tracking issue for the implementation of this RFC?

@nixos-discourse
Copy link

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

https://discourse.nixos.org/t/2024-02-15-documentation-team-meeting-notes-109/39826/1

@nixos-discourse
Copy link

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

https://discourse.nixos.org/t/tweag-nix-dev-update-54/39990/1

KAction pushed a commit to KAction/rfcs that referenced this pull request Apr 13, 2024
Co-authored-by: figsoda <figsoda@pm.me>
Co-authored-by: Anderson Torres <torres.anderson.85@protonmail.com>
Co-authored-by: gilice <104317939+gilice@users.noreply.github.com>
Co-authored-by: Florian Klink <flokli@flokli.de>
Co-authored-by: Mykola Orliuk <virkony@gmail.com>
Co-authored-by: asymmetric <lorenzo@mailbox.org>
Co-authored-by: Lassulus <github@lassul.us>
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
Co-authored-by: Silvan Mosberger <github@infinisil.com>
Co-authored-by: Adam Joseph <54836058+amjoseph-nixpkgs@users.noreply.github.com>
lf- pushed a commit to lix-project/lix that referenced this pull request Apr 28, 2024
For a long time `nix repl` has supported displaying documentation set on
builtins, however, it has long been convention to use Markdown comments
on Nix functions themselves for documentation. This exposes that
information to `nix repl` users in a nice and formatted way.

NixOS/rfcs#145 doc-comments are primarily what this feature is intended
to consume, however, support for lambda documentation in the repl is
experimental. We do our best effort to support the RFC here.

These changes are based on [the nix-doc library](https://github.com/lf-/nix-doc) and
are licensed under the terms described in the relevant source files.

Change-Id: Ic6fe947d39a22540705d890737e336c4720b0a22
lf- pushed a commit to lix-project/lix that referenced this pull request May 4, 2024
For a long time `nix repl` has supported displaying documentation set on
builtins, however, it has long been convention to use Markdown comments
on Nix functions themselves for documentation. This exposes that
information to `nix repl` users in a nice and formatted way.

NixOS/rfcs#145 doc-comments are primarily what this feature is intended
to consume, however, support for lambda documentation in the repl is
experimental. We do our best effort to support the RFC here.

These changes are based on [the nix-doc library](https://github.com/lf-/nix-doc) and
are licensed under the terms described in the relevant source files.

Change-Id: Ic6fe947d39a22540705d890737e336c4720b0a22
@roberth roberth mentioned this pull request Jul 9, 2024
@AndersonTorres
Copy link
Member

Since this was merged, please someone mark this as accepted.
Or there something to be decided still?

@GetPsyched (the last one I remember with labeling rights)

@GetPsyched GetPsyched added status: accepted and removed status: FCP in Final Comment Period labels Jul 15, 2024
@GetPsyched
Copy link
Member

Thanks for the reminder. Must've been missed at the time. Fixed.

@nixos-discourse
Copy link

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

https://discourse.nixos.org/t/2024-07-08-nix-team-meeting-minutes/49099/1

@nixos-discourse
Copy link

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

https://discourse.nixos.org/t/2024-11-23-24-zhf-24-11-hackathon-ost-zurich-rapperswil-jona/51634/3

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.