Use quarto to build online docs for a python package?

[jeffwong]

I write a lot of software libraries for R. My favorite tools are RMarkdown and pkgdown to build online documentation. The pkgdown articles, that are powered by Rmarkdown, allow me to avoid the hassle of copy-pasting the output of examples of my code.

Has anyone tried to use quarto to build online docs for a python package? I think it would really enrich the experience past mkdocs

[miwojc]

nbdev by fastai uses quarto for buidling docs for python packages
https://nbdev.fast.ai/

[ABohynDOE]

Recently quartodoc came out. It aims to act as a substitute for sphinx to build a python package documentation.
You could then use the rendered docs to publish it on github pages or readthedocs.

[mcanouil]

Changing to Q&A and marking https://pypi.org/project/quartodoc/ as the answer.

[ryan-kipawa]

I noticed that quartodoc's repository is owned by @machow instead of @quarto-dev. For package maintainers considering switching to quarto + quartodoc over sphinx, it would be useful to better understand the relationship between these projects. I think their combination is a great solution for the documentation of some python packages. Any guidance related to visions, roadmaps, and/or support plans for python documentation would be appreciated 😄

[cscheid]

Any guidance related to visions, roadmaps, and/or support plans for python documentation would be appreciated 😄

Disclosure: @machow and I both work for Posit, but on different capacities. I will only comment for myself.

As a Quarto dev, I am a big fan of quartodoc, and hope it will continue to be the great tool that it is. We have discussed moving Quartodoc to quarto-dev, in the past, but the main reason for not doing it is precisely so that there's a degree of separation between the two projects. I would want quartodoc to be able to move faster and make changes that might not be aligned with Quarto's changes, and vice-versa. We work together, regularly consult with each other, and want the two projects to be the best versions of themselves that they can be, but that does not mean that they should be developed in lockstep or with the same processes!

In addition, let me say something about roadmaps in quarto-dev/quarto-cli. As a matter of policy, quarto-cli doesn't offer official roadmaps (and I'm the lead dev, and the driver behind this decision). This is because I believe roadmaps are ultimately not a good communication mechanism for a resource-constrained team such as ours. Quarto is currently a three-person team, and there's too much volatility in what happens around the project to be able to give good promises. I can't speak for @machow, but if the project were to move to quarto-dev and the kinds of policies we prefer, it would make it more likely that quartodoc would not offer an official roadmap.