plot_calibration gives .data errors, based on type of plot, when following evalcast tutorial

[zterner-mitre]

I am trying to replicate the tutorial found at https://cmu-delphi.github.io/covidcast/evalcastR/articles/evalcast.html on my local machine. Things generally work (thanks Dmitry!) up until plot_calibration.

The first instance of plot_calibration is giving this issue, which occurs in format_wedgeplot, but refers to subsetting .data outside of a data mask context.

The second instance gives an identical issue and traceback to the first.

The third instance gives a similar subsetting .data issue, but says it occurs in format_traditional_calib_plot.

Are there packages on my end that I am missing and need to install/update?

[dshemetov]

Can reproduce. Taking a look into this...

[brookslogan]

This error is due to a newer version of rlang or maybe dplyr catching a pre-existing bug in the evalcast plotting code. Quick patches would be:

• Cloning this repo, and commenting out both uses of labs (or just the title setting) in R-packages/evalcast/R/plot_calibration.R, devtools::load_all().
• Downgrading rlang.

---

fad379fa8b0e2f76ecc4484f7d6425bcca09dbb7 introduced the .data$ part of this, maybe because a package check was warning about [the precursor to this issue: referring to some global variables]. But actually/now, it [wasn't a real/full fix; it just changed from suspiciously referencing globals to invalidly referencing .data$name etc., but old rlang/dplyr allowed that to happen and just gave NULL for .data$name]. Prior to this commit, I'd guess we somehow had global variables name and ahead set someplace (maybe in the vignette), but don't have them anymore [which continued to "work" because we switched to .data$name etc. which give NULL regardless of whether or not there is a global].

Fixes on our side: we could remove the title = part or try to correct it to what it was meant to produce.

[Hopefully a better description of the timeline:

• (Guess) we probably had name & ahead globals in the vignette, and the plotting functions were relying on those globals.
• R CMD CHECK complained that this is bad + about a bunch of other things that look like this problem but were actually legitimate dplyr usage.
  • We assumed they were all legit dplyr usage and added .data$ everywhere. But in this particular part it was invalid usage of .data$. .data$name etc. at the time returned NULL , which made sprintf give weird labels but not error.
• (Guess) we probably removed the globals that would have been used if we didn't prefix by .data$, so removing .data$ now doesn't work.
• rlang or dplyr updated to give errors when .data$ is misused this way, rather than NULL.]