> Is there a reason that this slightly more explicit > version [assign(envir=.GlobalEnv)] wouldn't work?
https://cran.r-project.org/web/packages/policies.html - Packages should not modify the global environment (user’s workspace). Bill Dunlap TIBCO Software wdunlap tibco.com On Thu, Sep 3, 2020 at 2:36 PM Ben Bolker <bbol...@gmail.com> wrote: > > Is there a reason that this slightly more explicit version wouldn't work? > > pali_string_fix <- function() { > assign("pali_alphabet", stringi::stri_unescape_unicode(pali_alphabet), > .GlobalEnv) > } > > > On 9/3/20 5:25 PM, Dan Zigmond wrote: > > Thanks, Gabor. I want these to be easily available to package users though > > – that's why they are in the package. So I would rather not "hide" them in > > a local environment. This is fundamentally a data package, so access to > > this data is the primary point of installing it. > > > > Is there any other solution? > > > > Dan > > > > . > > -------------------------- > > Dan Zigmond > > d...@shmonk.com > > > > > > > > On Thu, Sep 3, 2020 at 1:40 PM Gábor Csárdi <csardi.ga...@gmail.com> wrote: > > > >> Store the cached data in an environment within the package: > >> > >> pali_data <- new.env(parent = emptyenv()) > >> > >> pali_string_fix <- function() { > >> pali_data$alphabet <- > >> stringi::stri_unescape_unicode(pali_alphabet) > >> ... > >> } > >> > >> Gabor > >> > >> On Thu, Sep 3, 2020 at 9:33 PM Dan Zigmond <d...@shmonk.com> wrote: > >>> > >>> Hi, all. I am developing a package that includes some global variables. > >>> Because these are non-ASCII, I have escaped them. But then because these > >>> are difficult to read, I want to provide an easy way for users to > >> unescape > >>> all of them up front. Thus I have code like to create and save the data > >> in > >>> global variables in one file: > >>> > >>> pali_vowels <- > >>> c("a", "\u0101", "i", "\u012b", "u", "\u016b", "e", "o") > >>> pali_consonants <- > >>> c("k", "kh", "g", "gh", "\u1e45", > >>> "c", "ch", "j", "jh", "\u00f1", > >>> "\u1e6d", "\u1e6dh", "\u1e0d", "\u1e0dh", "\u1e47", > >>> "t", "th", "d", "dh", "n", > >>> "p", "ph", "b", "bh", "m", > >>> "y", "r", "l", "v", "s", "h", "\u1e37", "\u1e43") > >>> pali_alphabet <-c(pali_vowels, pali_consonants) > >>> use_data(pali_alphabet, overwrite = TRUE) > >>> > >>> and then I try to export a function like this in another file: > >>> > >>> pali_string_fix <- function() { > >>> pali_alphabet <<- > >>> stringi::stri_unescape_unicode(pali_alphabet) > >>> # Several more of these... > >>> } > >>> > >>> The idea is that users can run pali_string_fix() once when they load the > >>> package and then they won't need to deal with all the Unicode escape > >>> sequences after that. > >>> > >>> However, this is getting rejected by the CRAN checks with the message: > >>> > >>> * checking R code for possible problems ... [4s] NOTE > >>> pali_string_fix: no visible binding for '<<-' assignment to > >>> 'pali_alphabet' > >>> > >>> I'm guessing this is because the data and the function are defined in > >>> different files, so even though those globals are defined by my package, > >>> that isn't obvious when the check is run on this code. > >>> > >>> Does anyone have advice for how to fix this? > >>> > >>> Dan > >>> > >>> . > >>> ------------------------- > >>> Dan Zigmond > >>> d...@shmonk.com > >>> > >>> [[alternative HTML version deleted]] > >>> > >>> ______________________________________________ > >>> R-package-devel@r-project.org mailing list > >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel > >> > > > > [[alternative HTML version deleted]] > > > > ______________________________________________ > > 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 ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
