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 you recommend. I've lately being
trying to make a point of using the "tidy" stuff, as that's what I'm
seeing almost exclusively from folks in my neighborhood these days.
("Resistance is few-tile...")
Also, it would seem to be a corollary that if the ultimate goal is to
make a package, then one shouldn't be using the convenience stuff
(pipes, dplyr, etc., etc.), even during the development stages. Can
you comment? Thanks.
-- Mike
On Tue, Jul 17, 2018 at 2:53 AM, Mark van der Loo
<mark.vander...@gmail.com> wrote:
> 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
> results, and second, it adds several layers to the call stack making the
> output of functions like traceback() harder to interpret. I have documented
> a simple example here: https://github.com/chriscardillo/norris/issues/1
> (scroll down a bit).
>
> Regarding learning about quosures and so on. If the literal names of data
> frames are known, you could consider replacing
>
> some_var <- next_data_frame %>% dplyr::select(-amount,...
>
> with something simpler like
>
> some_var <- next_data_frame[ names(next_data_frame) != c("amount", ... ) ]
>
> which might also save you some dependencies.
>
>
>
>
> Hope this helps,
> Best,
> Mark
>
>
>
> Op di 17 jul. 2018 om 11:28 schreef Michael Hannon
> <jmhannon.ucda...@gmail.com>:
>>
>> 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 <zkam...@gmail.com> wrote:
>> > 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
>> >
>> > Hope that helps.
>> >
>> > On Jul 16, 2018, at 22:13 , Michael Hannon <jmhannon.ucda...@gmail.com>
>> > wrote:
>> >
>> > 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 still not entirely "happy" with me, but it
>> > doesn't flag any errors, and the package builds and runs.
>> >
>> > BTW, one source of "complaints" from "check()" is evidently the use of
>> > NSE in the tidyverse functions. For instance, the line:
>> >
>> > next_data_frame %>% dplyr::select(-amount,
>> >
>> > generates the message:
>> >
>> > standardize_format: no visible binding for global variable ‘amount’
>> >
>> > where, of course, "amount" is one of the column headings in
>> > "next_data_frame". There seems to be no harm done by this, and I plan
>> > to ignore such messages, but if there's some additional wisdom that
>> > applies here, I'd be happy to receive it.
>> >
>> > -- Mike
>> >
>> >
>> > On Sun, Jul 15, 2018 at 12:05 AM, Georgi Boshnakov
>> > <georgi.boshna...@manchester.ac.uk> wrote:
>> >
>> >
>> > 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. See
>> > ?Startup, especially section Note.
>> > It is difficult to give more specific advice without details of your
>> > setup.
>> >
>> >
>> > Hope this helps,
>> > Georgi Boshnakov
>> >
>> >
>> > ________________________________________
>> > From: R-package-devel [r-package-devel-boun...@r-project.org] on behalf
>> > of
>> > Michael Hannon [jmhannon.ucda...@gmail.com]
>> > Sent: 15 July 2018 02:13
>> > To: r-package-devel@r-project.org
>> > Subject: [R-pkg-devel] Package builds, installs, and runs but does not
>> > pass
>> > devtools::check()
>> >
>> > 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)
>> >
>> >
>> > the package loads without error, and the two exported functions appear
>> > to work as advertised.
>> >
>> > OTOH, if I include devtools::check() in the construction of the
>> > package, I consistently get an error:
>> >
>> > * installing *source* package ‘my_pkg’ ...
>> > ** R
>> > ** preparing package for lazy loading
>> > Error in loadNamespace(from, lib.loc = .library) :
>> > there is no package called ‘dplyr’
>> > Error : unable to load R code in package 'my_pkg'
>> >
>> > Clearly there *is* a package called "dplyr" on my system (see the
>> > session info below, for instance). And, as I've mentioned, the code
>> > *does* run, and I can watch it successfully reading CSV files.
>> >
>> > Here's the relevant part of my DESCRIPTION file:
>> >
>> > Depends: R (>= 3.4.4)
>> > Imports: readr,
>> > dplyr,
>> > ggplot2,
>> > purrr,
>> > magrittr
>> >
>> > I suspect the problem may be that I'm misunderstanding something about
>> > the `import::from()` function, which I'm using for the first time to
>> > load required functions into my code. In each of the three files that
>> > use dplyr I have the line:
>> >
>> > import::from(dplyr, mutate, filter, rename, select, setdiff, slice,
>> > "%>%")
>> >
>> > I've tried:
>> >
>> > (1) putting that line in just one of the files (the lexically first
>> > one)
>> > (2) including different subsets of dplyr functions, as needed, in
>> > the various files
>> >
>> > Needless to say, I haven't seen any improvement with any of the above
>> > (or any of the other thrashing I've done).
>> >
>> > If you can point me in the right direction, I'd appreciate it. Thanks.
>> >
>> > -- Mike
>> >
>> >
>> > session_info()
>> >
>> > Session info
>> > ------------------------------------------------------------------
>> > setting value
>> > version R version 3.4.4 (2018-03-15)
>> > system x86_64, linux-gnu
>> > ui X11
>> > language en_US
>> > collate en_US.UTF-8
>> > tz America/Los_Angeles
>> > date 2018-07-14
>> >
>> > Packages
>> > ----------------------------------------------------------------------
>> > package * version date source
>> > assertthat 0.2.0 2017-04-11 CRAN (R 3.3.3)
>> > base * 3.4.4 2018-03-16 local
>> > bindr 0.1.1 2018-03-13 CRAN (R 3.4.3)
>> > bindrcpp 0.2.2 2018-03-29 CRAN (R 3.4.4)
>> > compiler 3.4.4 2018-03-16 local
>> > crayon 1.3.4 2017-09-16 CRAN (R 3.4.1)
>> > datasets * 3.4.4 2018-03-16 local
>> > devtools * 1.13.6 2018-06-27 CRAN (R 3.4.4)
>> > digest 0.6.15 2018-01-28 CRAN (R 3.4.3)
>> > dplyr * 0.7.6 2018-06-29 CRAN (R 3.4.4)
>> > glue 1.2.0 2017-10-29 CRAN (R 3.4.2)
>> > graphics * 3.4.4 2018-03-16 local
>> > grDevices * 3.4.4 2018-03-16 local
>> > magrittr 1.5 2014-11-22 CRAN (R 3.2.2)
>> > memoise 1.1.0 2017-04-21 CRAN (R 3.3.3)
>> > methods * 3.4.4 2018-03-16 local
>> > pillar 1.3.0 2018-07-14 CRAN (R 3.4.4)
>> > pkgconfig 2.0.1 2017-03-21 CRAN (R 3.4.0)
>> > purrr 0.2.5 2018-05-29 CRAN (R 3.4.4)
>> > R6 2.2.2 2017-06-17 CRAN (R 3.4.0)
>> > Rcpp 0.12.17 2018-05-18 CRAN (R 3.4.4)
>> > rlang 0.2.1 2018-05-30 CRAN (R 3.4.4)
>> > stats * 3.4.4 2018-03-16 local
>> > tibble 1.4.2 2018-01-22 CRAN (R 3.4.3)
>> > tidyselect 0.2.4 2018-02-26 CRAN (R 3.4.3)
>> > utils * 3.4.4 2018-03-16 local
>> > withr 2.1.2 2018-03-15 CRAN (R 3.4.3)
>> >
>> >
>> >
>> > ______________________________________________
>> > R-package-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> >
>> >
>> > ______________________________________________
>> > R-package-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> >
>> >
>>
>> ______________________________________________
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
