[R-pkg-devel] Passing CRAN checks for a package linking to a system library on CRAN machines

[Tomas Kalibera]

On 5/14/21 4:19 AM, SN248 wrote:
> Thank you Tomas and Sokol for your suggestions.
>
> Based on Tomas' suggestion, it seems the best way forward would be to 
> first request CRAN maintainers to install libsbml on the CRAN 
> machines. It is quite straightforward to install the library from the 
> instructions provided online. If the installation fails on a 
> particular architecture, I should try bundling the source code and 
> creating the static libraries.

Please let me clarify, I am not suggesting that you ask CRAN team to 
create the distribution packages for you, but only to install an 
existing distribution package (in case they are not doing that already).

The distribution package is usually a script which automatically 
downloads the software, builds it, picks up the results, adds some 
meta-data about dependencies, and archives them in a supported format. 
Someone has to create the distribution package, and I am suggesting that 
you as R package maintainer should do that, possibly getting help from 
other volunteers e.g even on the R-devel mailing list. The CRAN team 
would only add that package name to their list of installed packages (in 
case it is not there implicitly, i.e. they possibly won't have to do 
anything).

So first, I would should check for existing distribution packages. Most 
distributions have their own indexing/search support, but you can also 
look online as follows.

For Linux distributions, there is e.g. pkgs.org for the first quick 
search (libsml-devel, libsbml-dev might be what you are looking for).

For Windows, msys2 packages are here 
https://github.com/msys2/MINGW-packages/, rtools packages are here 
https://github.com/r-windows/rtools-packages (so there is 
mingw-w64-libsbml). MXE packages are here 
https://github.com/mxe/mxe/tree/master/src and the customized version 
for R is here 
https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/toolchain_libs/mxe/src/ 
(so upstream MXE doesn't have sbml, but the customized has libsbml).

For macOS, recipes for R are here 
https://github.com/R-macos/recipes/tree/master/recipes and it does not 
have sbml library as far as I can see.

So, if you wanted your package to use sbml, the best way would be to 
test it with the sbml package from all the distributions mentioned above 
(from Linux, at least the ones used by CRAN - Debian/Ubuntu, Fedora). 
Then, you would create a recipe (distribution package) for macOS, test 
it with your package, and contribute to the "recipes" above. When 
creating the recipe, look at other recipes to get the form, and look at 
sbml in the previously mentioned distributions to see how to 
download/build it (in addition to the online manual you mentioned).

Once that is in, you could submit your package to CRAN, following the 
usual checks you do when submitting packages. And then, in case it 
failed on some of the CRAN machines, you could contact the individual 
maintainer and ask for installing that distribution package of the given 
name. In some cases it won't be necessary (the machines would already 
have the package, they may be installing all available packages 
automatically).

This may sound like a bit of work, but that is the price for adding 
dependencies on native libraries, and someone has to do this work. 
Installing libraries manually on the check machines is not going to 
scale and may be too much burden for many end users, apart from 
difficulties with repeatability, maintenance, etc.

Best
Tomas

>
> Thanks again for your help.
> Satya
>
> On Thu, May 13, 2021 at 2:28 AM Tomas Kalibera 
> <tomas.kalibera using gmail.com <mailto:tomas.kalibera using gmail.com>> wrote:
>
>
>     On 5/13/21 7:06 AM, SN248 wrote:
>     > I am working on a package which provides an interface to the
>     libsbml C++
>     > library (http://sbml.org/Software/libSBML
>     <http://sbml.org/Software/libSBML>) in R. The source code of this
>     > package (r2sbml) can be found at the following link
>     >
>     > https://github.com/sn248/r2sbml <https://github.com/sn248/r2sbml>
>     >
>     > The package passes CRAN checks with `R CMD check` on my machine,
>     but I do
>     > have dependency (libsbml library) installed on my machine (OSX) with
>     > headers and static libs at the usual locations, i.e.,
>     /usr/local/include
>     > and /usr/local/lib. The package also passes CRAN check on a
>     Windows machine
>     > with libsbml installed using Rtools40 and msys2. The DESCRIPTION
>     file lists
>     > libsbml in SystemRequirements but `R CMD check` obviously fails
>     on rhub
>     > machines because there are no instructions to install libsbml
>     first. As I
>     > understand, I have the following options to pass checks on CRAN
>     >
>     > 1. Bundle the source code of libsbml into the package and make
>     the static
>     > libs on the fly. I don't really want to try this approach even
>     though I
>     > have used this approach before in another package as I think
>     creating the
>     > static lib is not as straightforward for this library because of
>     the large
>     > number of files and complex dependency chart.
>     >
>     > 2. Include header files in the `inst` folder and pull the static
>     libs from
>     > rwinlib github (assuming the libs can be posted there). I am not
>     sure if
>     > this approach will work on all platforms on which CRAN checks
>     take place.
>     >
>     > 3. Somehow include instructions to install libsbml on CRAN
>     machines (I have
>     > no idea how to do this), or request CRAN maintainers to install
>     libsbml
>     > with header files and libs at usual locations (i.e.,
>     /usr/local/include and
>     > /usr/local/lib).
>     >
>     > I am sure some version of this question has been asked before as
>     there are
>     > many packages which interface with C/C++ libraries listed as
>     > SystemRequirements, but I could not find a clear answer to this
>     aspect,
>     > i.e., passing checks on CRAN machines.
>     >
>     > Any guidance here and pros/cons of the above mentioned
>     approaches will be
>     > very helpful.
>
>     I think the best way for maintenance and end users is when the
>     libraries
>     are part of common software distributions R is used with on each
>     platforms, which are also installed on CRAN machines. For Linux these
>     are popular distributions including Debian, Ubuntu, Fedora. For
>     Windows
>     this is customized msys2 (rtools) and customized mxe. For macOS
>     this is
>     a custom distribution ("recipes").
>
>     So, if your library is already present in those distributions, but
>     not
>     installed on some of the CRAN machines, I'd simply ask for it to be
>     installed - the installation is trivial in that case, this is what
>     the
>     distributions are for.
>
>     If the library is not present in those distributions, the next best I
>     think is to contribute it to them. In case of Windows, ideally
>     contribute also to the upstream vanilla distributions, not just to
>     the
>     customized versions for R. This would allow most people to benefit
>     from
>     your contribution, and the additional burden on CRAN maintainers (who
>     have to deal with many thousands of packages) would be minimized.
>
>     If all that failed, and the license allows, one can include the
>     source
>     code of the library into the package, but that creates burden on
>     users
>     as well as maintainers (of the package, but also the repository).
>     It may
>     create confusion about the configuration due to duplication between
>     packages. It creates burden for repository maintainers. It takes
>     additional time on installation (particularly some libraries heavily
>     using C++ take forever to build, and repository maintainers do
>     that very
>     often).
>
>     Downloading pre-compiled binaries (static libraries) at installation
>     time is the worst option in my view. It is non-transparent,
>     non-repeatable, and the binaries may be incompatible (e.g. on Windows
>     all object files have to be built for the same C runtime). It makes
>     maintenance of R much harder, currently the transition from MSVCRT to
>     UCRT on Windows.
>
>     Best
>     Tomas
>
>     >
>     > Thanks
>     > Satya
>     >
>     >       [[alternative HTML version deleted]]
>     >
>     > ______________________________________________
>     > R-package-devel using r-project.org
>     <mailto:R-package-devel using r-project.org> mailing list
>     > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>     <https://stat.ethz.ch/mailman/listinfo/r-package-devel>
>

	[[alternative HTML version deleted]]