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

Bill Dunlap w||||@mwdun|@p @end|ng |rom gm@||@com
Sat Apr 24 22:56:39 CEST 2021 

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 <maechler using 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?
>
>     > 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
>
> ______________________________________________
> R-package-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

	[[alternative HTML version deleted]]

More information about the R-package-devel mailing list