Hi Tomas, these are really helpful suggestions, which are not at all discussed in the current Writing R Extensions, nor in CRAN Repository Policy. Would you please consider adding this information to one of these official sources of documentation?
On Fri, May 14, 2021 at 3:59 AM Tomas Kalibera <tomas.kalib...@gmail.com> wrote: > > 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.kalib...@gmail.com <mailto:tomas.kalib...@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@r-project.org > > <mailto:R-package-devel@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]] > > ______________________________________________ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > [[alternative HTML version deleted]] ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
