similar to: Package tests: best practices

Ok, here's another best practices question - let's say I'm writing a package and I want to use a function name that is already claimed by a function in the base R packages. For the sake of argument, let's pretend this function is for profiling the performance of a function (like Rprof for example), and so an obvious name that comes to mind is profile. This, of course, clashes

On 30/01/2018 11:39 PM, Hadley Wickham wrote: > On Tue, Jan 30, 2018 at 4:55 PM, Duncan Murdoch > <murdoch.duncan at gmail.com> wrote: >> On 30/01/2018 4:30 PM, Kenny Bell wrote: >>> >>> In response to Duncan regarding the use of roxygen2 from the point of view >>> of a current user, I believe the issue he brings up is one of correlation >>>

Hi all, Am I using the correct syntax to set a custom R_LIBS when running R CMD INSTALL from the command line? I get: R_LIBS=/Users/hadley/R-dev R CMD INSTALL aL3xa-rapport-08e68ca/ # Desktop : R_LIBS=/Users/hadley/R-dev R CMD INSTALL aL3xa-rapport-08e68ca/ # * installing to library ?/Users/hadley/R? # ERROR: dependency ?ascii? is not available for package ?rapport? But: ls

On Thu, Feb 1, 2018 at 1:29 PM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > On 31/01/2018 6:59 AM, Duncan Murdoch wrote: > >> On 30/01/2018 11:39 PM, Hadley Wickham wrote: >> > [ lots deleted ] > >> Personally, I don't find writing in comments any harder than writing >>> in .Rd files, especially now that you can write in markdown and

On 31/01/2018 6:59 AM, Duncan Murdoch wrote: > On 30/01/2018 11:39 PM, Hadley Wickham wrote: [ lots deleted ] >> Personally, I don't find writing in comments any harder than writing >> in .Rd files, especially now that you can write in markdown and have >> it automatically translated to Rd formatting commands. > > I didn't know about the possibility of

>> There is package.skeleton() in base R as you already mentioned. It drove >> me >> bonkers that it creates packages which then fail R CMD check, so I wrote a >> wrapper package (pkgKitten) with another helper function (kitten()) which >> calls the base R helper and then cleans up it---but otherwise remains >> faithful to it. > > > Failing R CMD check

Dear R developers, I am wondering what are the best practices for developing an R package. I am aware of Hadley Wickham's best practice documentation/book (http://r-pkgs.had.co.nz/). I recall a couple of years ago there were some tools for generating a package out of a single file, such as using package.skeleton, but no auto-generated documentation. Do you know a way to generate

Section 1.4 of Writing R Extensions says: In addition to the help files in Rd format, R packages allow the inclusion of documents in arbitrary other formats. The standard location for these is subdirectory inst/doc of a source package, the contents will be copied to subdirectory doc when the package is installed. Pointers from package help indices to the installed documents are automatically

Dear all, ggplot currently requires 13 packages (grid, reshape, RColorBrewer, proto, splines, MASS, Hmisc, boot, butler, hexbin, mapproj, quantreg, sm). Some of these are absolutely necessary (eg. proto), but most are used for one or two specific tasks (eg. boot is only used to get plogis, used for logit scales). Do you think I should make them all "depends" packages, or

Hi all, The documentation for substitute currently reads: Substitution takes place by examining each component of the parse tree as follows: If it is not a bound symbol in ?env?, it is unchanged. If it is a promise object, i.e., a formal argument to a function or explicitly created using ?delayedAssign()?, the expression slot of the promise replaces the symbol. If it is an ordinary variable,

On Tue, 2018-01-30 at 17:00 +0100, Suzen, Mehmet wrote: > Dear R developers, > > I am wondering what are the best practices for developing an R > package. I am aware of Hadley Wickham's best practice > documentation/book (http://r-pkgs.had.co.nz/).??I recall a couple of > years ago there were some tools for generating a package out of a > single file, such as using

> >> I am wondering what are the best practices for developing an R > >> package. I am aware of Hadley Wickham's best practice > >> documentation/book (http://r-pkgs.had.co.nz/).??I recall a couple of > >> years ago there were some tools for generating a package out of a > >> single file, such as using package.skeleton, but no auto-generated

I'm putting together an R package. I would like to show example code in the vignette, where example data files (included in the package) are used to generate an (example) output file. I read about using example data in Hadley Wickham's post ( http://r-pkgs.had.co.nz/data.html), and believe I should keep my example data as raw data, as it must be parsed to generate the output. So, I

On Mon, Apr 22, 2024 at 5:14?PM Simon Urbanek <simon.urbanek at r-project.org> wrote: > > > > On Apr 22, 2024, at 7:37 PM, Gabriel Becker <gabembecker at gmail.com> > wrote: > > > > Hi Yutani, > > > > ALTREP is part of the official R api, as illustrated by the presence of > > src/include/R_ext/Altrep.h. Everything declared in the header

It is indeed a matter of what the developer is comfortable with and the one-stop solution provided by devtools is difficult to beat. This may also vary across projects. I use EMACS/ESS with and without roxygen2. In some cases EMACS/ESS+Org mode provides stunning benefits. Updating "usage" statements in Rd files was mentioned several times. Rdpack::reprompt() does this and more for

Hi all, I was wondering if any one had scripts that they could share for capturing the current version of R packages used for a project. I'm interested in creating a project local library so that you're safe if someone (e.g. the ggplot2 author) updates a package you're relying on and breaks your code. I could fairly easily hack together, but I was wondering if any one had any neat

I'm always forgetting to update the date in DESCRIPTION. Would it be possible to add a warning to R CMD check if it's old? Hadley -- http://had.co.nz/

Dear Duncan, With all respect, but I strongly disagree on your stance regarding roxygen2 for multiple reasons: 1. It is in my humble opinion not correct to evaluate a tool based on the abuse of some users. It's not because people write packages with bad documentation, that roxygen2 is to blame. I use roxygen2, and I care a great deal about documentation. So I actually took a bit offense

On 30/01/2018 11:29 AM, Brian G. Peterson wrote: > On Tue, 2018-01-30 at 17:00 +0100, Suzen, Mehmet wrote: >> Dear R developers, >> >> I am wondering what are the best practices for developing an R >> package. I am aware of Hadley Wickham's best practice >> documentation/book (http://r-pkgs.had.co.nz/).??I recall a couple of >> years ago there were some

On Tue, Jan 30, 2018 at 4:55 PM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > On 30/01/2018 4:30 PM, Kenny Bell wrote: >> >> In response to Duncan regarding the use of roxygen2 from the point of view >> of a current user, I believe the issue he brings up is one of correlation >> rather than causation. > > > Could be. However, I think editing