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

Custom template for protoc-gen-doc #121

Closed
Tracked by #140
paweld2 opened this issue Mar 29, 2021 · 6 comments
Closed
Tracked by #140

Custom template for protoc-gen-doc #121

paweld2 opened this issue Mar 29, 2021 · 6 comments
Labels
enhancement New feature or request lang-doc Doc rules specific plugin Regarding external plugins resolved-next-release Code to resolve issue is pending release
Milestone

Comments

@paweld2
Copy link

paweld2 commented Mar 29, 2021

For the protoc-gen-doc rules, I would like to use a custom template.

This is the official documentation of how to use custom templates:
https://github.com/pseudomuto/protoc-gen-doc/wiki/Custom-Templates

I assume that the rule could look like this:
doc_template_compile(
name = "place_doc_proto",
template = "customTemplate.tmpl",
protos = ["@rules_proto_grpc//example/proto:place_proto"],
)

As a example, I created a merge request to a add reStructuredText template to protoc-gen-doc:
pseudomuto/protoc-gen-doc#440

I could implement the rule, but I need some guide about how to pass the template file as a data to the protoc plugin execution. What I am missing specifically is: how to pass arguments from the rule,throw the aspect, to the plugin.

@aaliddell aaliddell added enhancement New feature or request lang-doc Doc rules specific plugin Regarding external plugins labels Apr 1, 2021
@aaliddell
Copy link
Member

This'd have to behave a little differently from the other doc rules, since it would have to accept a label that needs to be merged into the options attr in the underlying compilation. This isn't directly supported right now, but there should be a workable solution

@jrusso1020
Copy link

Was just looking for this, we would also like to pass in a custom template that we define potentially for our proto docs (markdown output)

@jrusso1020
Copy link

jrusso1020 commented Aug 17, 2021

@aaliddell Just curious, with the work done in #54 to support additional options being passed to a plugin, could we do something similar out of the box? Passing in a local custom template file

i.e.

I assume that the rule could look like this:

doc_markdown_compile(
  name = "place_doc_proto",
  protos = ["@rules_proto_grpc//example/proto:place_proto"],
  options = {
          "*": ["path/to/customtemplate.tmpl"],  # <- Applied to all plugins in rule
      }
)

@aaliddell
Copy link
Member

That’s similar to how I’d like to do this, but the difficulty arises in telling Bazel to make that file available to protoc invocation sandbox. There is no mechanism presently for that in these rules, so we’d need a ‘doc_template_compile’ rule that has a ‘template’ attr or similar. Internally we’d then need a mechanism for poking extra files into the protoc action.

@jrusso1020
Copy link

jrusso1020 commented Aug 17, 2021

I see, thanks for the explanation! I had a feeling that would be the limitation in that bazel wouldn't know about that file unless we had a bazel rule (as you a said doc_template_compile) which knows about the template file

@aaliddell aaliddell added this to the 4.0.0 milestone Sep 14, 2021
@aaliddell aaliddell mentioned this issue Sep 16, 2021
10 tasks
@aaliddell
Copy link
Member

I'm adding this in 4.0.0:

doc_template_compile(
    name = "something.txt",
    output_mode = "NO_PREFIX",
    protos = [
        ":some_proto",
    ],
    template = "template.txt",
)

@aaliddell aaliddell added the resolved-next-release Code to resolve issue is pending release label Sep 21, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request lang-doc Doc rules specific plugin Regarding external plugins resolved-next-release Code to resolve issue is pending release
Projects
None yet
Development

No branches or pull requests

3 participants