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.so...@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@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
