renderthis
renderthis copied to clipboard
new package / new package name?
I'm starting to tinker with quarto revealjs presentations, and they're pretty slick. It also got me thinking more about what {xaringanBuilder}
actually does, and I'm realizing that it can be used for much more than just xaringan presentations. Other than the few xaringan-specific functions where it takes the .Rmd file as the input (e.g., build_social()
), all the other functionality works for revealjs presentations. I also use it all the time to convert pdfs into png files to share individual slides or to make a thumbnail for a video, etc.
With this in mind, I was thinking perhaps we should consider re-naming it, or just start a new package based on {xaringanBuilder}
that has a broader purpose? Something that users of xaringan, revealjs, etc. could all use to renders their presentations (and other media) to different formats?
I was checking names, and both {buildr}
and {printr}
already exist on CRAN. But {build}
and {render}
are both available. I was thinking of simplifying the function names to just be the output type, so if you changed the package name it'd look something like this in use:
-
build::pdf()
,build::png()
,build::html()
-
render::pdf()
,render::png()
,render::html()
My preference is for a verb package name, like {build}
since it has the same feel of the current functions (e.g., build::pdf()
instead of xaringanBuilder::build_pdf()
). It's also so much easier to type...{xaringanBuilder}
is kind of an annoyingly long name.
Thoughts?
Naming is hard! I like the build, render, print root words, but they're also quite loaded with many definitions in the R world. For example, there's a lot of variety in the buildr packages.
Of the three, I like render
since it's the best match for the action — xaringanBuilder basically provides variations on rmarkdown::render()
— and it's also the verb Quarto uses — quarto render
.
But I'm hesitant to use the bare verb since it could make it harder to find. I also know I would feel pressured by the package name render
to do too much: render all the things or all the formats, etc. But with something with a small modification, it's a little easier to say no to some things.
Here's a quick brain dump of ideas:
-
rendermy
-
renderme
-
renderit
-
rendera
-
rendrele
(render the in French) -
renderthe
-
renderizar
(Portuguese) -
renderizer
-
renderify
Btw, have you seen pak::pkg_name_check()
? Very helpful here!
> pak::pkg_name_check("renderizar")
╔══════════════════════════════════════════════════════════════════════════════╗
║ –*– renderizar –*– ║
╚══════════════════════════════════════════════════════════════════════════════╝
┌──────────────────────────────────────────────────────────────────────────────┐
│ ✔ valid name ✔ CRAN ✔ Bioconductor ✔ not a profanity │
└──────────────────────────────────────────────────────────────────────────────┘
┌ Wikipedia ───────────────────────────────────────────────────────────────────┐
│ Renderizar No definition found │
└──────────────────────────────────────────────────────────────────────────── ┘
┌ Wiktionary ──────────────────────────────────────────────────────────────────┐
│ renderizar No English definition found │
└─────────────────────────────────── https://en.wiktionary.org/wiki/renderizar ┘
┌ Acroynms (from Acromine) ────────────────────────────────────────────────────┐
│ No acronyms found. │
└──────────────────────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────────────────────┐
│ Sentiment: 😐 (0) │
└──────────────────────────────────────────────────────────────────────────────┘
Agree on render
as the more appropriate verb than build
, and also that the pure render
name sounds like promising too much.
How do you feel about changing the function names to just the output types, e.g., build_pdf()
-> pdf()
?
The good thing about starting with a common prefix word is it's easier to search. If the package is loaded, you just start typing build_
and you'll get the autofill options for all the build_*
functions (this was my motivation for the function names in xaringanBuilder
).
That said, you can get a similar functionality by calling the function directly from the package, like pkgname::pdf()
. So with a good package name choice, this could be a nice solution that has a similar feel in use.
Some other potentials (all of these look good using pak::pkg_name_check()
:
-
rendr
(maybe too close torender
?) -
renderize
-
rendify
-
renderthis
(shout out tousethis
)
Oh I like renderthis::to_pdf()
!
I really like renderthis
. I started playing around with it to see how it feels: https://github.com/jhelvy/renderthis
Still need to adjust some things, in particular the example used in the documentation. But I like it overall.
I also changed the function names from build_*
-> to_*
, so it should feel more natural now (e.g., renderthis::to_pdf()
).
I also changed the argument names:
-
input
->from
-
output_file
->to
(maybe could change this tointo
)
So now it's renderthis::to_pdf(from = "slides.Rmd", to = "slides.pdf")
Just a starting point.
It looks great, I think we found a good name and naming pattern!
Closing this as I've now ported everything over to https://github.com/jhelvy/renderthis
Perhaps I closed this pre-maturely. Now that we're working over on {renderthis}, what to do with {xaringanBuilder}?
The history of issues here is a useful resource. Perhaps we should add a large-font notification at the top of the {xaringanBuilder} readme saying that development has moved to {renderthis}? And maybe also in the {renderthis} readme a link back to the {xaringanBuilder} issues page for potentially related issues?
Another option would be to rename this repo to renderthis
. You'd have to move the current renderthis out of the way and then you can rename this repo. That keeps all of the history and issues, etc., plus GitHub will put in redirects that send people from jhelvy/xaringanBuilder
to jhelvy/renderthis
. I'm pretty sure that will also work for devtools::install_github("jhelvy/xaringanBuilder")
--> devtools::install_github("jhelvy/renderthis")
.
Of course, the slog for us would be that there's a bit of work that has happened over in the current renderthis repo that would need to be ported back.
Hmm...I didn't know about the redirect thing. My concern was that people would try to go to jhelvy/xaringanBuilder and be using an outdated package. But if they're redirected to jhelvy/renderthis, that's no longer a problem. I agree about the history and issues - there's a lot of development in this repo. And there are common issues that we can link to.
I don't think it would be too much work to make the update here. Most of the work is done already in jhelvy/renderthis, so we could just start a new branch and overwrite most of the files with those in jhelvy/renderthis. Or you could perhaps try to use your Github wizard skills to port over the change history from jhelvy/renderthis to jhelvy/xaringanBuilder. I think all I'd have to do is change jhelvy/renderthis to something like jhelvy/renderthistemp, then we could change jhelvy/xaringanBuilder to jhelvy/renderthis and port things over from jhelvy/renderthistemp.
I think all I'd have to do is change jhelvy/renderthis to something like jhelvy/renderthistemp, then we could change jhelvy/xaringanBuilder to jhelvy/renderthis and port things over from jhelvy/renderthistemp.
yeah this is the way to go. I'm pretty certain you have to rename the repo (i.e. change xaringanBuilder
--> renderthis
) for GitHub to put the redirects in place. But that keeps the history and continuity, so worth it!
And then yeah, I can probably do some git ninja moves to shuffle commits from one place to another to bring commits from renderthistemp
back home to this repo.
Okay let me do this. Pretty sure nobody else is using jhelvy/renderthis except us, so I'll change it to jhelvy/renderthistemp, then I'll change jhelvy/xaringanBuilder to jhelvy/renderthis. If I break stuff hopefully I can just revert it all.
Just made the changes, redirect is working as expected for the repo link.
Documentation link isn't auto redirecting though.
Gets a 404: https://jhelvy.github.io/xaringanBuilder Works, and displays the pkgdown site on the gh-pages branch: https://jhelvy.github.io/renderthis
Cynkra has a good article for how to handle redirecting from jhelvy.github.io/xaringanBuilder
to jhelvy.github.io/renderthis
, which involves putting the right files in https://github.com/jhelvy/jhelvy.github.io to set up a redirect.
Edit: oops here's the link https://www.cynkra.com/blog/2021-04-09-deprecating-pkgdown/
okay, I'm going to try to replay the commits from renderthistemp
onto this new renderthis
. That may involve pushing to main... I'll report back here how it goes 🤞
@jhelvy Okay, I've moved all the commits in renderthistemp@main
to the main
branch here. I think it's ready for you to make main
the default branch in the repo settings. That'll complete the transition to renderthis! Once you make that change, I'd recommend deleting the master
branch so that nobody gets confused.
Next up I'll bring the handouts changes back to the pr branch but you don't need to wait for me.
New branch is main
!
master
is no more!
Edit: I have no idea how you do this witchcraft but it's amazing!
Okay, perhaps deleting master
wasn't a good idea just yet as it closed the PR for handouts. But the PR on renderthistemp is still available, so maybe we can just switch that one over to here?
🤦 oops but I think it's still recoverable. I'll see if I can resurrect it later today.
fyi I inserted an index.html page at https://jhelvy.github.io/xaringanBuilder/ to direct users to https://jhelvy.github.io/renderthis/
I think we can close this now :)