[R-pkg-devel] suggestion: conda for third-party software
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 at 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 at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel