You can include Unicode strings in a package, either as data, or just as character vectors. Or character vectors returned by functions. Many packages do that. E.g. cli:::symbol_utf8$tick is Unicode (not exported, but it could be).
The only restriction is that the source file must be ASCII, i.e. you need to create these vectors with `\u` escapes. For example the tick in cli is created like this: https://github.com/r-lib/cli/blob/e3ca34656f5bb82df63bfc1c741e75acc79b13d9/R/symbol.R#L27 When you print it (e.g. with something like `cat(cli:::symbol_utf8$tick)`) the proper Unicode character is printed, as long as the platform supports it. E.g. on macOS: ❯ cli:::symbol_utf8$tick [1] "✔" Gabor On Thu, Sep 3, 2020 at 11:26 PM Dan Zigmond <d...@shmonk.com> wrote: > > I get that, but these variables are created by the package. It's a data > package so the whole point is to provide access to the data. I'm just > trying to provide an option to make the data more readable since I can't > include Unicode strings directly in the package. In other words, these > variables (eg, pali_alphabet) will already exist when the user attaches the > package – but is there a way I can tweak them after the package has been > loaded? > > Dan > > . > -------------------------- > Dan Zigmond > d...@shmonk.com > > > > On Thu, Sep 3, 2020 at 2:56 PM William Dunlap <wdun...@tibco.com> wrote: > > > > 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 > > > > [[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
