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

Reply via email to