[R-pkg-devel] Using ggplot2 within another package

[Martin Maechler]

>>>>> 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
    >>> <https://ggplot2.tidyverse.org/articles/ggplot2-in-packages.html>
    >>> 
    >>> Cheers,
    >>> 
    >>> -Robert
    >>> 
    >>> On Thu, Apr 22, 2021 at 4:39 PM Paul SAVARY
    >>> <paul.savary using univ-fcomte.fr <mailto:paul.savary using 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" <kevin.r.coombes using gmail.com
    >>> <mailto:kevin.r.coombes using gmail.com>>
    >>> À: "r-package-devel" <r-package-devel using r-project.org
    >>> <mailto:r-package-devel using r-project.org>>
    >>> 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()
    >>> }
    >>> 
    >>> Of course, "R CMD check --as-cran" complains that there is no global
    >>> binding for "myX" or "myY" since they are columns defined in the
    >>> data.frame "myData".
    >>> 
    >>> What is the best way to work around this issue?
    >>> 
    >>> Of course, dinosaurs like myself might be tempted to suggest just
    >>> using
    >>> plain old "plot", so I don't need to see those suggestions.
    >>> 
    >>> Do I just ignore the usual ggplot conventions and write "myData$myX"
    >>> inside "aes"  in order to appease the CRAN checker? Or is there some
    >>> tidy-er way to solve this problem?
    >>> 
    >>> Thanks,
    >>>    Kevin
    >>> 
    >>> ______________________________________________
    >>> R-package-devel using r-project.org
    >>> <mailto:R-package-devel using r-project.org> mailing list
    >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
    >>> <https://stat.ethz.ch/mailman/listinfo/r-package-devel>
    >>> 
    >>> ______________________________________________
    >>> R-package-devel using r-project.org
    >>> <mailto:R-package-devel using r-project.org> mailing list
    >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
    >>> <https://stat.ethz.ch/mailman/listinfo/r-package-devel>
    >>> 
    >> 
    >> 
    >> [[alternative HTML version deleted]]
    >> 
    >> ______________________________________________
    >> R-package-devel using r-project.org mailing list
    >> https://stat.ethz.ch/mailman/listinfo/r-package-devel
    >> 

    > ______________________________________________
    > R-package-devel using r-project.org mailing list
    > https://stat.ethz.ch/mailman/listinfo/r-package-devel