Johan Andresen
2023-Jun-06 16:55 UTC
[R-sig-Debian] why is KEYWORDS.db not in '/usr/lib/R/doc/' but in '/usr/share/R/doc/'?
Hi r-sig-debian, I feel lucky to have found out that `/doc/KEYWORDS.db` is in `/usr/share/R/`, not in `usr/lib/R/` where rpy2 in python apparently looks for it when trying to search help in R from the python environment. it returned this error: `cannot open file '/usr/lib/R/doc/KEYWORDS.db': No such file or directory`. What to do now? - is this a problem with rpy2 looking for `/doc/KEYWORDS.db` that should not be in `usr/lib/R/`? -> *edit its script to point at the correct path?* - or is it a problem with R for debian bullseye putting `/doc/KEYWORDS.db` in '/usr/share/R/doc/' where it should not be? -> why does it do that? Should it be this way? Can I change it? To be sure, searching help in RStudio and `help('help`) in R from the terminal both worked. I installed both the way you suggest on lib.stat.cmu/R /CRAN/bin/linux/debian/. See also https://github.com/rpy2/rpy2/issues/1033 Johan with his first question on a, not just thus, mail list [[alternative HTML version deleted]]
Dirk Eddelbuettel
2023-Jun-06 17:20 UTC
[R-sig-Debian] why is KEYWORDS.db not in '/usr/lib/R/doc/' but in '/usr/share/R/doc/'?
Hi Johan, On 6 June 2023 at 18:55, Johan Andresen wrote: | Hi r-sig-debian, | | I feel lucky to have found out that `/doc/KEYWORDS.db` is in `/usr/share/R/`, | not in `usr/lib/R/` where rpy2 in python apparently looks for it when | trying to search help in R from the python environment. it returned this | error: `cannot open file '/usr/lib/R/doc/KEYWORDS.db': No such file or | directory`. | | What to do now? | - is this a problem with rpy2 looking for `/doc/KEYWORDS.db` that should | not be in `usr/lib/R/`? -> *edit its script to point at the correct path?* Yes, in essence. The longer story is that for (many, MANY) years we followed _Debian_ Policy where architecture-dependent files are in /usr/lib and architecture-indepdendent files are in /usr/share. As such we (ie Debian) differ from a "plain vanilla from source" installation. But then all (or most) other distros do too. It is the right (and/or was when multi-arch ie 32 and 64 bit was more common). Even R itself recently patched another accessor because the right way to do this is to expand the R.home() function rather than to append to the environment variable R_HOME (or RHOME). To show, on my system: > file.path( R.home("doc"), "KEYWORDS.db" ) [1] "/usr/share/R/doc/KEYWORDS.db" > So ideally rpy2 to should try to figure out where doc/ is for R and then append KEYWORDS.db. I am CCing Laurent now. | - or is it a problem with R for debian bullseye putting `/doc/KEYWORDS.db` | in '/usr/share/R/doc/' where it should not be? -> why does it do that? | Should it be this way? Can I change it? It was change brought to me (as Debian maintainer) by other Debian developers / Debian Policy. As such it is pretty irreversible. But "R known" and access via e.g. R.home() is the right way. Also not that /etc/R/Makeconf has, inter alia '--datadir=/usr/share/R/share' and include $(R_SHARE_DIR)/make/vars.mk MKINSTALLDIRS = "$(R_HOME)/bin/mkinstalldirs" R_XTRA_CPPFLAGS = -I"$(R_INCLUDE_DIR)" -DNDEB so R does have the notion of different directories just fine. Also: > envs <- Sys.getenv() > envs[grepl("^R_", names(envs))] R_ARCH R_BROWSER xdg-open R_BZIPCMD /bin/bzip2 R_DOC_DIR /usr/share/R/doc R_GZIPCMD /bin/gzip -n R_HOME /usr/lib/R R_INCLUDE_DIR /usr/share/R/include R_LIBS_SITE /usr/local/lib/R/site-library:/usr/lib/R/site-library R_LIBS_USER R_MAX_NUM_DLLS 500 R_PAPERSIZE letter R_PAPERSIZE_USER letter R_PDFVIEWER /usr/bin/xdg-open R_PLATFORM x86_64-pc-linux-gnu R_PRINTCMD /usr/bin/lpr R_RD4PDF times,inconsolata,hyper R_SESSION_TMPDIR /tmp/RtmpoU2ifO R_SHARE_DIR /usr/share/R/share R_STRIP_SHARED_LIB strip --strip-unneeded R_STRIP_STATIC_LIB strip --strip-debug R_SYSTEM_ABI linux,gcc,gxx,gfortran,gfortran R_TEXI2DVICMD /usr/bin/texi2dvi R_UNZIPCMD /usr/bin/unzip R_ZIPCMD /usr/bin/zip > | To be sure, searching help in RStudio and `help('help`) in R from the | terminal both worked. I installed both the way you suggest on lib.stat.cmu/R | /CRAN/bin/linux/debian/. | | See also https://github.com/rpy2/rpy2/issues/1033 Oh, nice, I should link back to this reply once it hits the mailing list archive. | Johan | with his first question on a, not just thus, mail list Thanks for the detailed and high-quality post. Keep'em coming! Dirk -- dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
Ivan Krylov
2023-Jun-06 17:25 UTC
[R-sig-Debian] why is KEYWORDS.db not in '/usr/lib/R/doc/' but in '/usr/share/R/doc/'?
Hello Johan and welcome to R-SIG-Debian! ? Tue, 6 Jun 2023 18:55:27 +0200 Johan Andresen <johan.andresen at gmail.com> ?????:> I feel lucky to have found out that `/doc/KEYWORDS.db` is in > `/usr/share/R/`, not in `usr/lib/R/` where rpy2 in python apparently > looks for it when trying to search help in R from the python > environment. it returned this error: `cannot open file > '/usr/lib/R/doc/KEYWORDS.db': No such file or directory`. > > What to do now? > - is this a problem with rpy2 looking for `/doc/KEYWORDS.db` that > should not be in `usr/lib/R/`? -> *edit its script to point at the > correct path?*It seems that R.home('doc') doesn't return the right path when running from under rpy2 for some reason. (With Debian packages, it should return "/usr/share/R/doc", not "/usr/lib/R/doc".) It's documented in ?R.home that on Unix-like OSes, the function relies on environment variables like R_DOC_DIR being set during startup. How does rpy2 launch R? It looks like rpy2 drives an embedded R like a frontend. I think that at least under Unix-alikes, the required environment variables are set by launching the frontend via `R CMD /path/to/frontend/executable` (see WRE 8.1 [*]), except this isn't convenient for the Python process. I guess rpy2 could obtain the additional variables the same way it currently extracts LD_LIBRARY_PATH.> Johan > with his first question on a, not just thus, mail list> [[alternative HTML version deleted]]One tiny detail: this mailing list (and other R project mailing lists) removes the HTML part of the messages it processes, so it's best to compose in plain text. But the rest of it you're doing absolutely right! -- Best regards, Ivan [*] https://cran.r-project.org/doc/manuals/R-exts.html#Embedding-R-under-Unix_002dalikes