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
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
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
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
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
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
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:
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
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.
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)
10 matches
Mail list logo