Search
32 results for “roxygen”
-
Experimenting with `@examplesWebR` - a new #roxygen2 tag that makes #rstats package examples interactive!
Instead of static code blocks, users get "View in webR REPL" buttons that open examples in their browser or the embedded webR REPL. No R installation needed!
Still WIP (🚧 ) since the main challenge is distributing dev packages for #webR (non-CRAN versions).
Would love input on the best approach! Here or:
-
TIL you can include multiple `#' @examples` and `#' @examplesIf` statements in your #roxygen2 #RStats code for conditional examples based on the user's system state.
I had previously thought that you could only use `#' @examples` OR `#' @examplesIf`, but never both. This is fantastic news!
https://github.com/cran/report/blob/ee8409bb541f7289154b16ca724ed2a3923eb660/R/report_info.R#L13-L34
-
Day 7: roxygen2 Advanced Tags and Cross-References 📝
Master documentation with advanced roxygen2 features, with markdown-style writing! 🎯
💡 Pro Tip: Use @inheritDotParams to inherit ... parameter documentation.
📚 Resources: https://roxygen2.r-lib.org -
The {document} #rstats 📦 creates roxygen2-style documentation for functions that aren't (yet) part of an R package.
In the screenshot below, top left shows a test.R file with a function called test_function , including roxygen definitions. After running
d <- document("test.R")
I can use
?test_function
to read the help file as if it were part of a package.
By Andreas Dominik Cullmann
https://cran.r-project.org/web/packages/document/vignettes/Introduction_to_document.html
-
Dear #rstats friends, remember all those tempdir()/tempfile() gymnastics for CRAN compliance?
examplesTempdir just made that circus act a one-liner with a simple #roxygen2 tag extension. Your future self will thank you.
-
And another ding for #VScode/#positron as a package developer: I cannot run #roxygen examples (at least I can still do that in #Nvim (or a simulacrum of it as long as I'm careful: https://github.com/R-nvim/R.nvim/issues/106))
[edit: I have to run the roxygen comments line-by-line: https://github.com/posit-dev/positron/issues/1410#issuecomment-1787438498]
https://github.com/posit-dev/positron/issues/2077
https://github.com/REditorSupport/vscode-R/issues/147 -
That was new. Mistakenly put a new function definition below an #RStats #ROxygen2 stub for exporting a method, and my NAMESPACE got very, very weird with stuff from the function description.
But faults on me for not looking at the NAMESPACE changes before committing and pushing the result.
Thankfully simple to fix. Move the function definition, delete the borked NAMESPACE, and {devtools::document()} to refresh it. Examine it, commit, push.
-
Recently ran into a disturbing #ChatGPT result: I asked it to translate a #python function written by Mathieu Daëron (https://github.com/mdaeron/D47crunch) to #R, using the #tidyverse and a #tibble. I had done this manually for my #rpackage https://github.com/isoverse/clumpedr/ and wanted to see how they would compare.
It returned my code literally, including TODO notes, comments, and #roxygen skeleton. But it did not say where it got the code from, even when pressed. My R package is on #github under #GPL 3. Thoughts?
-
1. write a function
2. write roxygen documentation
3. procrastinate for a hour
4. lunch
5. write unit tests -
1. write a function
2. write roxygen documentation
3. procrastinate for a hour
4. lunch
5. write unit tests -
1. write a function
2. write roxygen documentation
3. procrastinate for a hour
4. lunch
5. write unit tests -
1. write a function
2. write roxygen documentation
3. procrastinate for a hour
4. lunch
5. write unit tests -
Last month I switched over from using #NvimR to #RNvim (the lua-based successor), which uses #TreeSitter for syntax highlighting. It was hard enough to do the transition and the realize that debugging support was turned off, but one of the biggest disappointments is the lack of #roxygen highlighting (https://github.com/r-lib/tree-sitter-r/issues/68), which is actually default in #Nvim :blobfoxcry2: I was thinking to switch over to #VScode or #positron, but having to learn new shortcuts for everything make me sad.
-
@beps I truly understand what you mean. I am now talking a little about #RKWard. We have a solid integration of #git, #rio and some other tools. #quarto works. A tight integration of #styler would be nice. We have a good R console and a terminal. Likewise, we don't have the deep integration of #devtools, #roxygen2 and #pkgdown. Some find it good (I) others find it a hindrance.
In the end, there are many good choices. -
@beps I truly understand what you mean. I am now talking a little about #RKWard. We have a solid integration of #git, #rio and some other tools. #quarto works. A tight integration of #styler would be nice. We have a good R console and a terminal. Likewise, we don't have the deep integration of #devtools, #roxygen2 and #pkgdown. Some find it good (I) others find it a hindrance.
In the end, there are many good choices. -
@beps I truly understand what you mean. I am now talking a little about #RKWard. We have a solid integration of #git, #rio and some other tools. #quarto works. A tight integration of #styler would be nice. We have a good R console and a terminal. Likewise, we don't have the deep integration of #devtools, #roxygen2 and #pkgdown. Some find it good (I) others find it a hindrance.
In the end, there are many good choices. -
@beps I truly understand what you mean. I am now talking a little about #RKWard. We have a solid integration of #git, #rio and some other tools. #quarto works. A tight integration of #styler would be nice. We have a good R console and a terminal. Likewise, we don't have the deep integration of #devtools, #roxygen2 and #pkgdown. Some find it good (I) others find it a hindrance.
In the end, there are many good choices. -
@beps I truly understand what you mean. I am now talking a little about #RKWard. We have a solid integration of #git, #rio and some other tools. #quarto works. A tight integration of #styler would be nice. We have a good R console and a terminal. Likewise, we don't have the deep integration of #devtools, #roxygen2 and #pkgdown. Some find it good (I) others find it a hindrance.
In the end, there are many good choices. -
The Bottom Line: Manually editing DESCRIPTION = typos, wrong formatting, forgotten versions. usethis = automatic, correct, sorted. Let the tool handle the details so you focus on code.
Tomorrow: Advanced roxygen2 for better documentation! 📝Resources: https://usethis.r-lib.org
#rstats #usethis #Dependencies #RPackageAdvent2025 -
So not many people were keen on a weekly zoom for the intro to R packages (focussing on research project packages), but @mcaleerp suggested an intensive course. Would people be interested in a (free) 2-day course this summer covering setting up a package project, creating functions, documenting them with roxygen, creating vignettes, unit testing, package testing, version control with git, and distribution with github? It could be in Glasgow (my preference) or on Zoom, but not hybrid. #rstats #PsyTeachR
-
So not many people were keen on a weekly zoom for the intro to R packages (focussing on research project packages), but @mcaleerp suggested an intensive course. Would people be interested in a (free) 2-day course this summer covering setting up a package project, creating functions, documenting them with roxygen, creating vignettes, unit testing, package testing, version control with git, and distribution with github? It could be in Glasgow (my preference) or on Zoom, but not hybrid. #rstats #PsyTeachR
-
So not many people were keen on a weekly zoom for the intro to R packages (focussing on research project packages), but @mcaleerp suggested an intensive course. Would people be interested in a (free) 2-day course this summer covering setting up a package project, creating functions, documenting them with roxygen, creating vignettes, unit testing, package testing, version control with git, and distribution with github? It could be in Glasgow (my preference) or on Zoom, but not hybrid. #rstats #PsyTeachR
-
So not many people were keen on a weekly zoom for the intro to R packages (focussing on research project packages), but @mcaleerp suggested an intensive course. Would people be interested in a (free) 2-day course this summer covering setting up a package project, creating functions, documenting them with roxygen, creating vignettes, unit testing, package testing, version control with git, and distribution with github? It could be in Glasgow (my preference) or on Zoom, but not hybrid. #rstats #PsyTeachR
-
So not many people were keen on a weekly zoom for the intro to R packages (focussing on research project packages), but @mcaleerp suggested an intensive course. Would people be interested in a (free) 2-day course this summer covering setting up a package project, creating functions, documenting them with roxygen, creating vignettes, unit testing, package testing, version control with git, and distribution with github? It could be in Glasgow (my preference) or on Zoom, but not hybrid. #rstats #PsyTeachR
-
Dear R developers and CRAN maintainers, I wonder if you can kindly help me understand how I should deal with the import of some packages and package functions. Despite reading "R Packages" (eg <https://r-pkgs.org/dependencies-mindset-background.html>) and "Writing R Extensions" (eg <https://cran.r-project.org/doc/manuals/R-exts.html#Package-Dependencies>), I'm still unsure how to deal with the following situation.
Suppose you have a package with the following requirements:
1. *One* function in your package, say "funA" requires a whole package, say PKGA. *However*, the function only uses PKGA in a separate (parallel::makeCluster) process. This function is fundamental to your package, in the sense that the user will surely use it at least once in their workflow.
2. Another function in your package, say "funB", requires two functions "aux1" and "aux2" from another package, say PKGB. The user might use this function, or maybe not. In your code (no parallel invocation), the functions are called with PKGB::aux1 etc.
3. The two functions "aux1" and "aux2" from PKGB are also available in PKGA. You'd like to be sure that the user can choose freely which ones they want in their workflow, alongside your package. In other words, no masking should take place a priori.
Given these conditions, what should NAMESPACE and DESCRIPTION contain? With Roxygen, where should I use @ import and @ importFrom? and what about usethis::use_import()?
Thank you very much for any tips or extra references to read!
Edit: for the moment, my solution has been to include PKGA, PKGB, and parallel in the Imports field of the DESCRIPTION file, but not to have these three packages in the NAMESPACE file as Import(). This seems to achieve what i want, but I'm not sure it's the "proper" solution.
