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

[Serguei Sokol]

Le 08/01/2020 à 08:50, Ivan Krylov a écrit :
> 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.
The same would apply for my proposition: if you want, you use 
conda:something if not you do like before. But anyway, I don't make a 
campaign for 'conda:' tag in SystemRequirements. Kevin's Config/conda 
solution seems to be sufficient for this issue. Just, I was not aware 
that it was already there.

Best,
Serguei.