When doing a clean reinstall of R.nvim, I found that nvimcom successfully builds caches for all packages in my libraries except for the "translations" package that is installed by default by the CRAN windows installer.
In particular, the process fails when trying to get the object names in the package (shown in the lines below).
|
nvim.build.srcref <- function(srcref_file, libname) { |
|
packname <- paste0("package:", libname) |
|
obj.list <- objects(packname, all.names = TRUE) |
|
sink(srcref_file, append = FALSE) |
|
for (obj in obj.list) { |
|
fn <- try(get(obj, envir = as.environment(packname)), silent = TRUE) |
|
if (inherits(fn, "try-error") || !is.function(fn)) { |
|
next |
The reason for the failure is that the translations package does not have a NAMESPACE file. So an error is raised when trying to get the object names in the "package:translations" environment because there is no such environment.
It's possible that this has not come up in the past (or is not reproducible on some setups) for a few reasons:
- Users can opt out of installing the "translations" package in the CRAN installer, so they might never get this error
- It is one of the last packages in the list, so the error causes few problems as most srcref caches have already been built
- You have to look at :RDebugInfo to catch the error. It does not persist in :messages
The solution could be as simple as handling the error with try (as is done in the lines below) and setting obj.list to character(0), which will ensure an empty srcref cache is made so it is skipped in the future.
My hacky solution in the meantime is to just add an empty NAMESPACE file to the translations folder in my library.
When doing a clean reinstall of R.nvim, I found that nvimcom successfully builds caches for all packages in my libraries except for the "translations" package that is installed by default by the CRAN windows installer.
In particular, the process fails when trying to get the object names in the package (shown in the lines below).
R.nvim/nvimcom/R/bol.R
Lines 537 to 544 in c56ebe0
The reason for the failure is that the translations package does not have a NAMESPACE file. So an error is raised when trying to get the object names in the "package:translations" environment because there is no such environment.
It's possible that this has not come up in the past (or is not reproducible on some setups) for a few reasons:
The solution could be as simple as handling the error with try (as is done in the lines below) and setting obj.list to character(0), which will ensure an empty srcref cache is made so it is skipped in the future.
My hacky solution in the meantime is to just add an empty NAMESPACE file to the translations folder in my library.