Re: [R-pkg-devel] Package builds, installs, and runs but does not pass devtools::check()

2018-07-19 Thread Michael Hannon
Very nice discussion. Thanks, Mark. On Thu, Jul 19, 2018 at 3:20 AM, Mark van der Loo wrote: > > Dear Mike, et al, > > My remarks are not necessarily related to tidyverse packages. The main point > is that there are various purposes and business cases for writing code, and > they may imply

Re: [R-pkg-devel] Package builds, installs, and runs but does not pass devtools::check()

2018-07-19 Thread Mark van der Loo
Dear Mike, et al, My remarks are not necessarily related to tidyverse packages. The main point is that there are various purposes and business cases for writing code, and they may imply different trade-offs. Let me illustrate with some examples. I will focus on non-standard evaluation and

Re: [R-pkg-devel] Package builds, installs, and runs but does not pass devtools::check()

2018-07-17 Thread Michael Hannon
Thanks, Mark. Your points are well-taken, but I wouldn't refer to this as a "small side-track". You don't say so, but this could be interpreted as a recommendation to avoid some or all of the "tidyverse" in developing packages. I'm actually quite comfortable doing the base-R-style programming

Re: [R-pkg-devel] Package builds, installs, and runs but does not pass devtools::check()

2018-07-17 Thread Mark van der Loo
Michael, Just a small side-track here. I would avoid using the not-a-pipe operator within functions or packages in general. It is great for interactive use, but it does make debugging and hence long-term maintenance of functions harder. There are two reasons for this. First, it hides intermediate

Re: [R-pkg-devel] Package builds, installs, and runs but does not pass devtools::check()

2018-07-17 Thread Michael Hannon
Thanks to John and Zhian for their recent and informative comments. Regarding check() and NSE: the moral seems to be that a little learning is a dangerous thing. I'm off to try to bring quosure to this issue. -- Mike On Mon, Jul 16, 2018 at 2:38 PM, Zhian Kamvar wrote: > Using dplyr like

Re: [R-pkg-devel] Package builds, installs, and runs but does not pass devtools::check()

2018-07-16 Thread Zhian Kamvar
Using dplyr like that is for exploratory data analysis. You'll want to refer to dplyr's "Programming with dplyr" vignette for using dplyr in a package: https://cran.r-project.org/web/packages/dplyr/vignettes/programming.html

Re: [R-pkg-devel] Package builds, installs, and runs but does not pass devtools::check()

2018-07-16 Thread Fox, John
Dear Michael, You could add a call to globalVariables() in the package sources for cases like this. I hope this helps, John - John Fox Professor Emeritus McMaster University Hamilton, Ontario, Canada Web:

Re: [R-pkg-devel] Package builds, installs, and runs but does not pass devtools::check()

2018-07-16 Thread Michael Hannon
Thanks, Georgi. I've changed my approach and now do what I gather is recommended practice: put all external package names into the "Imports" section of the DESCRIPTION file and then use the fully-qualified names for functions from those packages, as: dplyr::select() The "check" operation is

Re: [R-pkg-devel] Package builds, installs, and runs but does not pass devtools::check()

2018-07-15 Thread Georgi Boshnakov
It seems that the R session used by 'check' doesn't look in the library used by your interactive session. This discrepancy may happen since the check tools do not load the same Renviron files as interactive sessions. This may result in different libraries in interactive and 'check' sessions.

[R-pkg-devel] Package builds, installs, and runs but does not pass devtools::check()

2018-07-14 Thread Michael Hannon
Greetings. I'm working on a small package, and I'm using the devtools functions to create, build, etc., the package. As indicated in the subject line, I get no errors when I do: > build() > install() When I run a separate R session and load the package, i.e., > library(my_pkg)