Le 08/01/2020 à 08:50, Ivan Krylov a écrit :
On Tue, 7 Jan 2020 15:49:45 +0100
Serguei Sokol <serguei.so...@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.
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
