Re: [R-pkg-devel] Using ggplot2 within another package
> Ben Bolker
> on Thu, 22 Apr 2021 17:27:49 -0400 writes:
> For some reason that I don't remember, an R core member once told me
> that they prefer x <- y <- NULL to utils::globalVariables(c("x","y")) -
That could have been me. Even though I think I still have some
globalVariables() statements in some of my package sources, I've
decided that it *harms* really, notably for relatively common variable names
such
as "x": It declares them "global"
{ for the purpose of codetools::globalVariables() } everywhere,
i.e. for all functions in the package namespace and that
basically kills the reliability of globalVariables() checking
for the whole package.
> although I have also encountered problems with that strategy in edge
cases.
well, when?
> Here's an example from StackOverflow from today where for some reason
> I don't understand, evaluation of function arguments interacts with
> non-standard/lazy evaluation within a dplyr function such that 'foo'
> works while 'x$foo' doesn't ... don't know if it's a similar case.
>
https://stackoverflow.com/questions/67218258/getting-error-error-in-usemethodfilter-no-applicable-method-for-filter/67220198#67220198
{ ceterum censeo ... to use NSE (non-standard-evaluation) for
user convenience and to call this (together with really good
ideas) "tidy" has been one of the biggest euphemisms in the history of
statistical computing ... but yes, that's just my personal opinon }
> On 4/22/21 5:19 PM, Kevin R. Coombes wrote:
>> Thanks.
>>
>> Obviously, long. long ago, (in a galaxy not far enough away), Paul's
>> suggestion of using "aes_string" was the correct one, since "aes" uses
>> non-standard evaluation. (And to quote somebody from an R fortune
>> cookie, "The problem with non-standard evaluation is that it is
>> non-standard.") But teh documentation at the end oft he link provided by
>> Robert explivityl tells you not to do that, since "aes_string is
>> deprecated". And reading more carefully into the manual page for
>> aes_string, one does indeed find the statement that the function is
>> "soft deprecated". I'm not sure what that means, other than someone on
>> the development team doesn't like it.
>>
>> Instead, the vignette says you should
>> importFrom("rlang", ".data")
>> in your NAMESPACE, and write
>> ggplot(myData, aes(x = .data$myX, y = .data$myY))
>>
>> And now my dinosaur question: That looks like using one non-standard
>> hack to cover up the problems with another non-standard hack. Why the
>> heck is that any better for the developer than writing
>> ggplot(myData, aes(x = myData$myX, y = myData$myY))
>>
>> or using Dirk Eddelbuettel's suggestion of calling
utils::globalVariables ??
>>
>> It's time to tell those kids to get off of my lawn.
>> Kevin
>>
>> On 4/22/2021 4:45 PM, Robert M. Flight wrote:
>>> Kevin,
>>>
>>> This vignette from ggplot2 itself gives the "officially recommended"
>>> ways to avoid the warnings from R CMD check
>>>
>>> https://ggplot2.tidyverse.org/articles/ggplot2-in-packages.html
>>>
>>>
>>> Cheers,
>>>
>>> -Robert
>>>
>>> On Thu, Apr 22, 2021 at 4:39 PM Paul SAVARY
>>> mailto:paul.sav...@univ-fcomte.fr>> wrote:
>>>
>>> Hi Kevin,
>>>
>>> I was faced to the same problem and I used 'aes_string()' instead
>>> of 'aes()'. You can then just write the name of the columns
>>> containing the data to plot as character strings.
>>>
>>> Example:
>>>
>>> myPlot <- function(myData, ...) {
>>> # get ready
>>> ggplot(myData, aes_string(x = "myX", y = "myY")) +
>>> # add my decorations
>>> theme_bw()
>>> }
>>>
>>> It is probably already the case for your function but you need to
>>> include #' @import ggplot2 in your function preamble (if I am not
>>> wrong).
>>>
>>> Kind regards
>>> Paul
>>>
>>> - Mail original -
>>> De: "Kevin R. Coombes" >> >
>>> À: "r-package-devel" >> >
>>> Envoyé: Jeudi 22 Avril 2021 22:28:55
>>> Objet: [R-pkg-devel] Using ggplot2 within another package
>>>
>>> Hi,
>>>
>>> I'm trying to help clean up an R package for someone else to
>>> submit to
>>> CRAN. He has used ggplot2 to implement a plotting function for the
>>> kinds
>>> of things that his packages generates. His plotting routine basically
>>> looks like (after changing names to protect the innocent):
>>>
>>> myPlot <- fucntion(myData, ...) {
>>> # get ready
>>> ggplot(myData, aes(x = myX, y = myY)) +
>>> # add my decorations
>>> theme_bw()
Re: [R-pkg-devel] Using ggplot2 within another package
Has there been any thought given to an alternative to globalVariables that
would flag certain arguments to certain functions as being evaluated in a
non-standard way. E.g.,
usesNSE(FUN="with.default", ARGUMENTS="expr")
usesNSE(FUN="lm", ARGUMENTS=c("weights","subset","offset"))
usesNSE(FUN="~") # missing ARGUMENTS means all args are NSE
This information would be stored in the environment that contains FUN.
-Bill
On Sat, Apr 24, 2021 at 6:18 AM Martin Maechler
wrote:
> > Ben Bolker
> > on Thu, 22 Apr 2021 17:27:49 -0400 writes:
>
> > For some reason that I don't remember, an R core member once told me
> > that they prefer x <- y <- NULL to
> utils::globalVariables(c("x","y")) -
>
> That could have been me. Even though I think I still have some
> globalVariables() statements in some of my package sources, I've
> decided that it *harms* really, notably for relatively common variable
> names such
> as "x": It declares them "global"
> { for the purpose of codetools::globalVariables() } everywhere,
> i.e. for all functions in the package namespace and that
> basically kills the reliability of globalVariables() checking
> for the whole package.
>
>
> > although I have also encountered problems with that strategy in edge
> cases.
>
> well, when?
>
> > Here's an example from StackOverflow from today where for some
> reason
> > I don't understand, evaluation of function arguments interacts with
> > non-standard/lazy evaluation within a dplyr function such that 'foo'
> > works while 'x$foo' doesn't ... don't know if it's a similar case.
>
> >
> https://stackoverflow.com/questions/67218258/getting-error-error-in-usemethodfilter-no-applicable-method-for-filter/67220198#67220198
>
>
> { ceterum censeo ... to use NSE (non-standard-evaluation) for
> user convenience and to call this (together with really good
> ideas) "tidy" has been one of the biggest euphemisms in the history of
> statistical computing ... but yes, that's just my personal opinon }
>
> > On 4/22/21 5:19 PM, Kevin R. Coombes wrote:
> >> Thanks.
> >>
> >> Obviously, long. long ago, (in a galaxy not far enough away), Paul's
> >> suggestion of using "aes_string" was the correct one, since "aes"
> uses
> >> non-standard evaluation. (And to quote somebody from an R fortune
> >> cookie, "The problem with non-standard evaluation is that it is
> >> non-standard.") But teh documentation at the end oft he link
> provided by
> >> Robert explivityl tells you not to do that, since "aes_string is
> >> deprecated". And reading more carefully into the manual page for
> >> aes_string, one does indeed find the statement that the function is
> >> "soft deprecated". I'm not sure what that means, other than someone
> on
> >> the development team doesn't like it.
> >>
> >> Instead, the vignette says you should
> >>importFrom("rlang", ".data")
> >> in your NAMESPACE, and write
> >>ggplot(myData, aes(x = .data$myX, y = .data$myY))
> >>
> >> And now my dinosaur question: That looks like using one non-standard
> >> hack to cover up the problems with another non-standard hack. Why
> the
> >> heck is that any better for the developer than writing
> >>ggplot(myData, aes(x = myData$myX, y = myData$myY))
> >>
> >> or using Dirk Eddelbuettel's suggestion of calling
> utils::globalVariables ??
> >>
> >> It's time to tell those kids to get off of my lawn.
> >> Kevin
> >>
> >> On 4/22/2021 4:45 PM, Robert M. Flight wrote:
> >>> Kevin,
> >>>
> >>> This vignette from ggplot2 itself gives the "officially
> recommended"
> >>> ways to avoid the warnings from R CMD check
> >>>
> >>> https://ggplot2.tidyverse.org/articles/ggplot2-in-packages.html
> >>>
> >>>
> >>> Cheers,
> >>>
> >>> -Robert
> >>>
> >>> On Thu, Apr 22, 2021 at 4:39 PM Paul SAVARY
> >>> mailto:paul.sav...@univ-fcomte.fr>>
> wrote:
> >>>
> >>> Hi Kevin,
> >>>
> >>> I was faced to the same problem and I used 'aes_string()' instead
> >>> of 'aes()'. You can then just write the name of the columns
> >>> containing the data to plot as character strings.
> >>>
> >>> Example:
> >>>
> >>> myPlot <- function(myData, ...) {
> >>> # get ready
> >>> ggplot(myData, aes_string(x = "myX", y = "myY")) +
> >>># add my decorations
> >>>theme_bw()
> >>> }
> >>>
> >>> It is probably already the case for your function but you need to
> >>> include #' @import ggplot2 in your function preamble (if I am not
> >>> wrong).
> >>>
> >>> Kind regards
> >>> Paul
> >>>
> >>> - Mail original -
> >>> De: "Kevin R. Coombes" >>> >
> >>> À: "r-package-devel" >>> <
Re: [R-pkg-devel] Using ggplot2 within another package
It seems that what we need is really ignoreLocalVariables() rather
than globalVariables() ... ?
On 4/24/21 4:56 PM, Bill Dunlap wrote:
Has there been any thought given to an alternative to globalVariables
that would flag certain arguments to certain functions as being
evaluated in a non-standard way. E.g.,
usesNSE(FUN="with.default", ARGUMENTS="expr")
usesNSE(FUN="lm", ARGUMENTS=c("weights","subset","offset"))
usesNSE(FUN="~") # missing ARGUMENTS means all args are NSE
This information would be stored in the environment that contains FUN.
-Bill
On Sat, Apr 24, 2021 at 6:18 AM Martin Maechler
mailto:maech...@stat.math.ethz.ch>> wrote:
> Ben Bolker
> on Thu, 22 Apr 2021 17:27:49 -0400 writes:
> For some reason that I don't remember, an R core member once
told me
> that they prefer x <- y <- NULL to
utils::globalVariables(c("x","y")) -
That could have been me. Even though I think I still have some
globalVariables() statements in some of my package sources, I've
decided that it *harms* really, notably for relatively common
variable names such
as "x": It declares them "global"
{ for the purpose of codetools::globalVariables() } everywhere,
i.e. for all functions in the package namespace and that
basically kills the reliability of globalVariables() checking
for the whole package.
> although I have also encountered problems with that strategy
in edge cases.
well, when?
Honestly, I don't remember. Something with order of evaluation and
the fact that a variable existed and was set to NULL in the package
namespace screwing things up.
> Here's an example from StackOverflow from today where for
some reason
> I don't understand, evaluation of function arguments
interacts with
> non-standard/lazy evaluation within a dplyr function such
that 'foo'
> works while 'x$foo' doesn't ... don't know if it's a similar
case.
>
https://stackoverflow.com/questions/67218258/getting-error-error-in-usemethodfilter-no-applicable-method-for-filter/67220198#67220198
{ ceterum censeo ... to use NSE (non-standard-evaluation) for
user convenience and to call this (together with really good
ideas) "tidy" has been one of the biggest euphemisms in the
history of
statistical computing ... but yes, that's just my personal opinon }
> On 4/22/21 5:19 PM, Kevin R. Coombes wrote:
>> Thanks.
>>
>> Obviously, long. long ago, (in a galaxy not far enough
away), Paul's
>> suggestion of using "aes_string" was the correct one, since
"aes" uses
>> non-standard evaluation. (And to quote somebody from an R
fortune
>> cookie, "The problem with non-standard evaluation is that it is
>> non-standard.") But teh documentation at the end oft he link
provided by
>> Robert explivityl tells you not to do that, since "aes_string is
>> deprecated". And reading more carefully into the manual
page for
>> aes_string, one does indeed find the statement that the
function is
>> "soft deprecated". I'm not sure what that means, other than
someone on
>> the development team doesn't like it.
>>
>> Instead, the vignette says you should
>> importFrom("rlang", ".data")
>> in your NAMESPACE, and write
>> ggplot(myData, aes(x = .data$myX, y = .data$myY))
>>
>> And now my dinosaur question: That looks like using one
non-standard
>> hack to cover up the problems with another non-standard
hack. Why the
>> heck is that any better for the developer than writing
>> ggplot(myData, aes(x = myData$myX, y = myData$myY))
>>
>> or using Dirk Eddelbuettel's suggestion of calling
utils::globalVariables ??
>>
>> It's time to tell those kids to get off of my lawn.
>> Kevin
>>
>> On 4/22/2021 4:45 PM, Robert M. Flight wrote:
>>> Kevin,
>>>
>>> This vignette from ggplot2 itself gives the "officially
recommended"
>>> ways to avoid the warnings from R CMD check
>>>
>>>
https://ggplot2.tidyverse.org/articles/ggplot2-in-packages.html
>>>
>
>>>
>>> Cheers,
>>>
>>> -Robert
>>>
>>> On Thu, Apr 22, 2021 at 4:39 PM Paul SAVARY
>>> mailto:paul.sav...@univ-fcomte.fr>
