[R-pkg-devel] suggestion: conda for third-party software

[Ivan Krylov]

On Tue, 7 Jan 2020 15:49:45 +0100
Serguei Sokol <serguei.sokol using gmail.com> wrote:

> Currently, many R packages include TPS as part of them thus bloating
> their sizes and often duplicating files on a given system.  And even
> when TPS is not included in an R package but is just installed on a
> system, it is not so obvious to get the right path to it. Sometimes
> pkg-config helps but it is not always present.

I agree that making a package depend on a third-party library means
finding oneself in a bit of a pickle. A really popular library like
cURL could be "just" depended upon (for the price of some problems when
building on Windows). A really small (e.g. 3 source files) and rarely
updated (just once last year) library like liborigin could "just" be
bundled (but the package maintainer would have to constantly watch out
for new versions of the library). Finding that the bundled version of a
network-facing library in an R package (e.g. libuv in httpuv) is several
minor versions out of date is always a bit scary, even if it turns out
that no major security flaws have been found in that version (just a few
low-probability resource leaks, one unlikely NULL pointer dereference
and some portability problems). The road to dependency hell is paved
with intentions of code reuse.

> So, the new feature would be to let R package developers to write in 
> DESCRIPTION/SystemRequirements field something like 
> 'conda:boost-cpp>=1.71' where 'boost-cpp' is an example of a conda 
> package and '>=1.71' is an optional version requirement.

While I appreciate the effort behind Anaconda, I would hate to see it
being *required* to depend on third-party binaries compiled by a
fourth-party (am I counting my parties right?) when there's already a
copy installed and available via means the user trusts more (e.g. via
GNU/Linux distro package, or Homebrew on macOS, or just a copy sitting
in /usr/local installed manually from source). In this regard, a
separate field like "Config/conda" suggested by Kevin Ushey sounds like
a good idea: if one wants to use Anaconda, the field is there. If one
doesn't, one can just ignore it and provide the necessary dependencies
in a different way.

-- 
Best regards,
Ivan