On Sat, Mar 23, 2019 at 9:46 PM Jack Wasey <j...@jackwasey.com> wrote: > > Thanks for that thought. I do also do this in that package, and the same > problem exists, since the code in those particular steps of R CMD check also > calls .onLoad. These steps might even attach the package: the R CMD check > code in tools is too convoluted for me to unravel, but the result is the > same: active bindings defined directly in the namespace, or inserted into it > from .onLoad, get run. .onAttach isn't possible because the namespace is > sealed already.
cli is on CRAN and checks OK with R CMD check. > In the example you offer from CLI, the binding is inserted into the "dummy" > function's immediately enclosing environment, which is AFAIK not the same as > the package namespace. It seems to me that it is the same, no? ❯ environment(cli:::dummy) <environment: namespace:cli> ❯ "symbol" %in% ls(environment(cli:::dummy)) [1] TRUE G. > Jack > > On 3/23/19 2:14 PM, Gábor Csárdi wrote: > > Hi, yet another workaround is to create the active binding in the > > .onLoad() function. Here is an example from the cli package: > > https://github.com/r-lib/cli/blob/d4756c483f69c2382c27b0b983d0ce7cc7e63763/R/onload.R#L8 > > > > Gabor > > > > On Sat, Mar 23, 2019 at 3:50 PM Jack O. Wasey <j...@jackwasey.com> wrote: > >> > >> Dear all, > >> > >> I am developing a package which is a front for various online data > >> (icd.data https://github.com/jackwasey/icd.data/ ). The current CRAN > >> version just has lazy-loaded data, but now the package encompasses far > >> more current and historic ICD codes from different countries, these > >> can't be included in the CRAN package even with maximal compression. > >> > >> Other authors have solved this using functions to get the data, with or > >> without a local cache of the retrieved data. No CRAN or other packages I > >> have found after extensive searching use the attractive active binding > >> feature of R. > >> > >> The goal is simple: for the user to refer to the data by its symbol, > >> e.g., 'icd10fr2019', or 'icd.data::icd10fr2019', and it will be > >> downloaded and parsed transparently (if the user has already granted > >> permission, or after prompt if they haven't). > >> > >> The bindings are set using commands alongside the function definitions > >> in R/*.R .E.g. > >> > >> makeActiveBinding("icd10cm_latest", .icd10cm_latest_binding, environment()) > >> lockBinding("icd10cm_latest", environment()) > >> > >> For non-interactive use, CI and CRAN tests, no data should be > >> downloaded, and no cache directory set up without user consent. For > >> interactive use, I ask permission to create a local data cache before > >> downloading data. > >> > >> This works fine... until R CMD check. The following steps seems to 'get' > >> or 'source' everything from the package namespace, which results in > >> triggering the active bindings, and this fails if I am unable to get > >> consent to download data, and want to 'stop' on this error condition. > >> - checking dependencies in R code > >> - checking S3 generic/method consistency > >> - checking foreign function calls > >> - checking R code for possible problems > >> > >> Debugging CI-specific binding bugs is a nightmare because these occur in > >> different R sessions initiated by R CMD check. > >> > >> There may be legitimate reasons to evaluate everything in the namespace, > >> but I've no idea what they are. Incidentally, Rstudio also does 'mget' > >> on the whole package namespace and triggers bindings during > >> autocomplete. https://github.com/rstudio/rstudio/issues/4414 > >> > >> Is this something I should raise as an issue with R? Or does anyone have > >> any idea of a sensible approach to this. Currently I have a set of > >> workarounds, but this complicates the code, and has taken an awful lot > >> of time. Does anyone know of any CRAN package which has active bindings > >> in the package namespace? > >> > >> Any ideas appreciated. > >> > >> Jack Wasey > >> > >> ______________________________________________ > >> 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