[R-pkg-devel] Wrapping a third-party c++ library
I am trying to wrap a third-party toolkit that provides a C++ API. The code is open source and includes a license that allows me to include it directly in an R package. Right now, I am happy if I can get ANY build (linux, windows, or Mac) working. The rough build process looks like that given here (starting at the highlighted line): https://github.com/seandavi/SRA2R/blob/master/inst/docker/install_ngs_sdk.sh#L22 Unfortunately, these configure scripts are not standard autoconfig flavor, so they seem pretty fragile (even with a —prefix, they try to install stuff into system libraries). My goal is to include the source of the two partner libraries and build shared libraries in the R installation hierarchy. I simply do not have enough experience using configure scripts to know how to translate what I have noted above into something that would be expected to get the installation right in the r package directory and allow linking. Any concrete suggestions about how to move this forward are much appreciated. Thanks, Sean signature.asc Description: Message signed with OpenPGP using GPGMail __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Wrapping a third-party c++ library
Thanks for the reply and feedback, Dirk. > On Aug 23, 2016, at 10:59 AM, Dirk Eddelbuettel wrote: > > > hi Sean, > > On 23 August 2016 at 09:13, Sean Davis wrote: > | I am trying to wrap a third-party toolkit that provides a C++ API. The > code is open source and includes a license that allows me to include it > directly in an R package. Right now, I am happy if I can get ANY build > (linux, windows, or Mac) working. The rough build process looks like that > given here (starting at the highlighted line): > | > | > https://github.com/seandavi/SRA2R/blob/master/inst/docker/install_ngs_sdk.sh#L22 > | > | Unfortunately, these configure scripts are not standard autoconfig flavor, > so they seem pretty fragile (even with a —prefix, they try to install stuff > into system libraries). My goal is to include the source of the two partner > libraries and build shared libraries in the R installation hierarchy. I > simply do not have enough experience using configure scripts to know how to > translate what I have noted above into something that would be expected to > get the installation right in the r package directory and allow linking. > | > | Any concrete suggestions about how to move this forward are much > appreciated. > > Local shared libraries is hard(est). I would not start there. > > System shared libraries is easy (just ask all the database packages, graphics > formats packages etc pp) -- but you then push the burden onto your users to > actually *have* these system libraries. Not easy with "obscure" science > stuff. It is complicated further by the fact that the group who develops this software distributes it as binaries to many users. > Middle ground: _static_ library in your package. Tweak and bend the required > libraries til they cooperate, then adjust. This has been done since time > immortal, see eg the Matrix package and its several subdirectories. Still > not trivial, but doable. Probably beyond my patience level, but…. > Easiest 'dirty' solution: throw all source files into your package's src/ and > hope for the best. Works for small packages. Yeah, I have tried that in the past and perhaps after some cleanup the code can get there. > Long story short: for something complicated like this, maybe a Docker > container is the best you can do :-/ Yeah, docker is what I have been living with for months and it is a great solution for development, but moving that paradigm the the standard scientific HPC environment just isn’t happening despite all the problems it would potentially bypass. Nice to know that, while my R foo is limited compared to others on this list, I am not crazy to think that this might be hard. Sean > > Dirk > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org signature.asc Description: Message signed with OpenPGP using GPGMail __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] DOI for archived package?
I have found reminding editors of this editorial to be useful: https://www.nature.com/articles/ng.2869 Community repositories that carry out testing are ideal for commonly used > programs (for example, those used in statistical analysis), and a fair > proportion of the genetics community is fortunately familiar with the > Comprehensive R Archive Network (http://cran.r-project.org/) and the > principles of stewardship of modular software embodied in the Bioconductor > suite (http://www.bioconductor.org/). The journal has sufficient > experience with these resources to endorse their use by authors. We do not > yet provide any endorsement for the suitability or usefulness of other > solutions but will work with our authors and readers, as well as with other > journals, to arrive at a set of principles and recommendations. > As a tangential but informational comment, Bioconductor started minting minimalist DOIs for packages a couple years ago. I do not think DOIs have seen broad uptake as a citation mechanism for Bioc packages (I states without evidence), but the opportunity arose to do so and we took it. https://github.com/seandavi/BiocPkgTools/blob/master/R/newBiocPkgDOI.R Sean On Thu, Sep 10, 2020 at 12:36 PM Iñaki Ucar wrote: > If you proposed > https://cran.r-project.org/src/contrib/Archive/ > /_.tar.gz > and the editor is suspicious about the "src/contrib/Archive" stuff, you > could propose instead > https://cran.r-project.org/package=&version=, > which *looks* more permanent I guess. > > Iñaki > > On Thu, 10 Sep 2020 at 18:14, Kevin R. Coombes > wrote: > > > Hi, > > > > I am in the process of submitting a "workflow" article about an R > > package (which is onCRAN) to F1000Research. The associate editor that I > > am dealing with wants a "DOI" for the source code of the package being > > described in the manuscript. I have already explained that CRAN > > archives all versions of packages, and I sent him the URL to the archive > > page for the package, However, he still seems to believe that a DOI > > needs to be assigned by some site like Zenodo. > > > > I haven't yet responded by pointing out that CRAN has been archiving all > > versions of packages since at least the year 2000, it has mirrors all > > over the world, and the URL/URI used here is likely to be far more > > permanent than the DOI from Zenodo. Nor have I pointed out that there > > are more than 15,000 packages at CRAN, nor that not a single R user > > would ever think to go look on Zenodo for an R package. > > > > Does anyone have other suggestions for how to respond? (I know; I could > > just put the [expletive] thing into Zenodo and move on, but creating a > > permanent identifier for something that will *never *be accessed just > > seems stupid.) > > > > Thanks, > >Kevin > > > > [[alternative HTML version deleted]] > > > > __ > > R-package-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-package-devel > > > > > -- > Iñaki Úcar > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > -- Sean Davis, MD, PhD Center for Cancer Research National Cancer Institute National Institutes of Health Bethesda, MD 20892 https://seandavi.github.io/ https://twitter.com/seandavis12 [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Retrieving versioned csv datasets for use in an R package
Hi, all. Zenodo does offer storage (I believe limited to 50GB per submission) and is backed by CERN with a guarantee of storage for at least 20 years (the life of CERN, could be extended). I agree that Github is a viable alternative to Zenodo and one can use the two together easily. On github, one can use three different approaches: 1) check files into version control, 2) use git lfs, and 3) as release artifacts. Each has pros and cons. If data are of a biomedical nature, one can ofter deposit in a biomedical repository, including one of dozens at NIH and EBI. NIH even recommends some open “generalist repositories” that include zenodo and OSF: https://www.nlm.nih.gov/NIHbmic/generalist_repositories.html If one is looking to cater to the machine learning/AI community, hosting on huggingface is another option. Doing so is quite similar to hosting on github from a purely practical perspective. Cloud storage systems such as AWS, GCP, and Azure are possibilities, but egress charges can be challenging to predict. Cloudflare R2 is s3-compatible and has no egress charges, making it a good choice for sharing particularly large files. On the client side, Bioconductor has BiocFileCache which is a client-side package for caching files that have been downloaded. Other file download/cache packages are available, though I’m less familiar with them. Just wanted to expand the list a bit. Sean From: R-package-devel on behalf of Dirk Eddelbuettel Date: Saturday, February 15, 2025 at 10:29 AM To: Simon Urbanek Cc: R-package-devel@r-project.org Subject: Re: [R-pkg-devel] Retrieving versioned csv datasets for use in an R package On 15 February 2025 at 19:50, Simon Urbanek wrote: | Github is not reliable enough for reproducible research (your files can | disappear at any point - or can change without notice), I'm curious: Do you have a concrete example of a no-longer-reproducible study whose data or other support files changed and thereby caused this breakage? | that's why Zenodo was created. But AFAIK Zenodo offers DOI issuance only, not storage (as, say, OSF would). So this does not address the problem faced by the OP. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ 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
