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

[Kevin Ushey]

The newest version of reticulate does something very similar: R
packages can declare their Python package dependencies in the
Config/reticulate field of a DESCRIPTION file, and reticulate can read
and use those dependencies to provision a Python environment for the
user when requested (currently using Miniconda).

Similarly, rather than having this part of SystemRequirements, package
authors could declare these in a separate field called e.g.
Config/conda. Then, you could have an R package that knows how to read
and parse these configuration requests, and install those packages for
the user.

That said, maintaining a Conda installation and its environments is
non-trivial, and things do not always work as expected when mixing
Conda applications with non-Conda applications. Most notably, Conda
installations bundle their own copies of libraries; e.g. the C++
standard library, Qt, OpenSSL, and so on. If an application tries to
mix and match both system-provided and Conda-provided libraries in the
same process, bad things often happen. This was still the
lowest-friction way forward for us with reticulate, but it's worth
being aware that Conda is not a total panacea.

Best,
Kevin

On Tue, Jan 7, 2020 at 6:50 AM Serguei Sokol <serguei.sokol using gmail.com> wrote:
>
> Best wishes for 2020!
>
> I would like to suggest a new feature for R package management. Its aim
> is to enable package developers and end-users to rely on conda (
> https://docs.conda.io/en/latest/ ) for managing third-party software
> (TPS) on major platforms: linux64, win64 and osx64. 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.
>
> 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. Having this
> could allow install.packages() to install TPS on a testing CRAN machine
> or on an end-user's one. (There is just one line to execute in a shell:
> conda install <pkg-name>. It will install the package itself as well as
> all its dependencies).
>
> To my mind, this feature would have the following advantages:
>   - on-disk size economy as the same TPS does not have to be included in
> R package itself and can be shared with other language wrappers, e.g.
> Python;
>   - an easy flag configuring in Makevars as paths to TPS will be well
> known in advance;
>   - CRAN machines could test packages relying on a wide panel of TPS
> without bothering with their manual installation;
>   - TPS installation can become transparent for the end-user on major
> platforms;
>
> Note that even R is part of conda (
> https://anaconda.org/conda-forge/r-base ), it is not mandatory to use
> the conda's R version for this feature. Here, conda is just meant to
> facilitate access to TPS. However, a minimal requirement is obviously to
> have conda itself.
>
> Does it look reasonable? appealing?
> Best,
> Serguei.
>
> ______________________________________________
> R-package-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel