Ivan,
I suspect that the `which' case is just the tip of the iceberg - generally, R
expects all tools it detects at configure time to be callable, just to list a
few from a running session:
PAGER /usr/bin/less
R_BROWSER /usr/bin/open
R_BZIPCMD /usr/bin/bzip2
R_GZIPCMD /usr/bin/gzip
R_PDFVIEWER /usr/bin/open
R_QPDF /Library/Frameworks/R.framework/Resources/bin/qpdf
R_TEXI2DVICMD /usr/local/bin/texi2dvi
R_UNZIPCMD /usr/bin/unzip
R_ZIPCMD /usr/bin/zip
SED /usr/bin/sed
TAR /usr/bin/tar
I would claim it is not an unreasonable expectation that the user doesn't
delete tools after R was built. Obviously it is tedious, but Spack may need to
patch all absolute paths if it wants to relocate things (it's not easy as it
includes all linker paths as well FWIW) - they must be doing something like
that already as even the R start-up script uses absolute paths:
$ grep ^R_ /Library/Frameworks/R.framework/Resources/bin/R
R_HOME_DIR=/Library/Frameworks/R.framework/Resources
R_HOME="${R_HOME_DIR}"
R_SHARE_DIR=/Library/Frameworks/R.framework/Resources/share
R_INCLUDE_DIR=/Library/Frameworks/R.framework/Resources/include
R_DOC_DIR=/Library/Frameworks/R.framework/Resources/doc
R_binary="${R_HOME}/bin/exec${R_ARCH}/R"
That said, WHICH is a mess - it may make sense to switch to the command -v
built-in which is part of POSIX (where available - which is almost everywhere
today) which would not require an external tool, but as noted I don't think
this is the only problem Spack has... (and that's just core R - even a bigger
can of worms with R packages :P).
Cheers,
Simon
> On Jan 11, 2024, at 8:43 AM, Ivan Krylov via R-devel <r-devel@r-project.org>
> wrote:
>
> Hello R-devel,
>
> Currently on Unix-like systems, Sys.which incorporates the absolute
> path to the `which` executable, obtained at the configure stage:
>
>> ## hopefully configure found [/usr]/bin/which
>> which <- "@WHICH@"
>> if (!nzchar(which)) {
>> warning("'which' was not found on this platform")
>
> This poses a problem for the Spack package manager and software
> distribution. In Spack, like in Nix, Guix, and GoboLinux, packages live
> under their own path prefixes, which look like the following:
>
>>> /opt/spack/opt/spack/linux-ubuntu18.04-x86_64_v3/gcc-7.5.0/r-4.3.0-eqteloqhjzix6ta373ruzt5imvvbcesc
>
> Unfortunately, Spack packages are expected to get relocated, changing
> the path prefix and invalidating stored paths, including the path to
> `which`: <https://github.com/spack/spack/issues/41953>.
>
> Harmen Stoppels, who is not subscribed to R-devel but interested in
> making R work in Spack, currently creates a symlink to `which`
> <https://github.com/r-devel/r-svn/pull/151> as part of a patch to R.
>
> What would be the minimally disruptive way to avoid this dependency or
> at least make it easier to fix post-factum, during relocation? What
> would be the pitfall if Sys.which() were to find `which` on the $PATH
> by itself, without remembering the full path?
>
> --
> Best regards,
> Ivan
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
