rmarkdown::render() removal question

[TimTaylor]

Hi @yihui - Starting this as a discussion rather than an issue as I'm aware the removal of rmarkdown support was a deliberate choice (a7c033d).

With that change we can no longer use pkgdown with basic vignettes (I'm aware this was somewhat fortuitous that it worked in the first place). Am I correct in assuming that litedown could never become a dependency of rmarkdown to be used within rmarkdown::render()? Not a problem if that is the case I will just need to expedite my search for a pkgdown alternative. On that note do you have a very rough ETA for the next litedown release (so I can ensure I have something in place by then)?

[yihui]

The next release should be in a month or so. If I can't make it before Christmas, it should be next year.

I didn't realize that a7c033d would affect pkgdown sites. I can partially revert the changes to make litedown::html_format continue to work for some time, but eventually I hope to remove it, since it's not a good idea to run rmarkdown::render() on litedown documents---knitr::knit() and litedown::fuse() are not totally compatible with each other, and the actual vignettes (rendered by litedown) may be different with those re-rendered by pkgdown. The goal of a7c033d was to remind users of the possible incompatibilities between knitr and litedown.

Regarding pkgdown alternatives, I'm not sure if you have seen #24. The basic components are ready in litedown, but it will be nicer for litedown to provide a website template (or even better, a reusable Github action) so people can render a package site in one function call like litedown::fuse_pkg(). @jangorecki has an experiment here: https://github.com/jangorecki/pkgup

Starting this as a discussion rather than an issue

I'm planning to close issues and switch to discussions entirely for this repo, and I'm glad that you created the first discussion :)

[TimTaylor]

The next release should be in a month or so. If I can't make it before Christmas, it should be next year.

Cheers - that's enough time for me to adapt should you want to keep the change. From CRAN packages it looks like there's only one other maintainer who could be affected at the moment (Charlie Gao - mirai/nanonext)

I didn't realize that a7c033d would affect pkgdown sites. I can partially revert the changes to make litedown::html_format continue to work for some time, but eventually I hope to remove it, since it's not a good idea to run rmarkdown::render() on litedown documents---knitr::knit() and litedown::fuse() are not totally compatible with each other, and the actual vignettes (rendered by litedown) may be different with those re-rendered by pkgdown. The goal of a7c033d was to remind users of the possible incompatibilities between knitr and litedown.

Makes sense. I was suprised when pkgdown initially worked so knew it was going to be an unsupported solution and that either pkgdown or litedown could make a change at any point.

Regarding pkgdown alternatives, I'm not sure if you have seen #24. The basic components are ready in litedown, but it will be nicer for litedown to provide a website template (or even better, a reusable Github action) so people can render a package site in one function call like litedown::fuse_pkg(). @jangorecki has an experiment here: https://github.com/jangorecki/pkgup

Id seen #24 but not Jan's proof of concept. I'll dig further. Thank you - Never enough time in the week though.

I'm planning to close issues and switch to discussions entirely for this repo, and I'm glad that you created the first discussion :)

Cool. GitHub showered me with a confetti animation 🎉 😁

[yihui]

I've been thinking of using the format field (like Quarto) instead of output in YAML.

---
format:
  html:
    options: ...
    meta: ...
  latex:
---

That way, it won't break pkgdown, and it will also be slightly easier to type the output format names.

The reason that litedown::*_format existed was because originally I only intended to rewrite the Pandoc part of R Markdown (the outcome was the markdown package). It was not until this year that I started considering rewriting knitr, and realized the code could be so much cleaner without having to support .Rnw / .Rhtml / .Rrst / ... With all the legacy stuff behind, there's no longer a reason to try to be compatible with rmarkdown::render().