Thanks Dirk and others -- I see the tradeoffs now. In my case, I think a simple copy of source (just a few files), plus maybe some sort of commit/tag reference to indicate where/when the source is coming from. -John
On Thu, Jan 23, 2025 at 3:47 PM Dirk Eddelbuettel <e...@debian.org> wrote: > > On 21 January 2025 at 12:04, Jonathan Berrisch wrote: > | first of all: I'm not an expert on this and don't really know if there > | is a recommended way. > | > | However, you may look at my 'rcpptimer' package and how it includes > | 'cpptimer' as a submodule. > | > | You can find the repository here: https://github.com/BerriJ/rcpptimer > > I had written a longer (private) email to John expressing the view that git > submodules "were once more 'en vogue'" but one sees them less these days. > One reason is that they break some (somewhat standard) workflows, see > below. > > Overall, this is "no win" situation. You can include the files in the > package > as a copy [2] enlarging the package, build process, etc but arguably making > it more robust, or you can keep it external which is cleaner -- but harder > as > you now have to ensure users (and CRAN !) can get / have that library. > > So it is all tradeoffs one has to make. > > Dirk > > > [1] Log from a standard r2u Ubuntu container, `git` and `ssh` added as > needed: > > root@4163d5544547:/# installGithub.r https://github.com/BerriJ/rcpptimer > Downloading GitHub repo BerriJ/rcpptimer@HEAD > '/usr/bin/git' clone --depth 1 --no-hardlinks --recurse-submodules > g...@github.com:BerriJ/cpptimer.git > /tmp/remotes257564d64e0/BerriJ-rcpptimer-35ca024/inst/include/cpptimer > Cloning into > '/tmp/remotes257564d64e0/BerriJ-rcpptimer-35ca024/inst/include/cpptimer'... > The authenticity of host 'github.com (140.82.113.3)' can't be established. > ED25519 key fingerprint is > SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU. > This key is not known by any other names. > Are you sure you want to continue connecting (yes/no/[fingerprint])? yes > Warning: Permanently added 'github.com' (ED25519) to the list of known > hosts. > g...@github.com: Permission denied (publickey). > fatal: Could not read from remote repository. > > Please make sure you have the correct access rights > and the repository exists. > Error: Failed to install 'rcpptimer' from GitHub: > Command failed (128) > In addition: Warning message: > In system(full, intern = TRUE, ignore.stderr = quiet) : > running command ''/usr/bin/git' clone --depth 1 --no-hardlinks > --recurse-submodules g...@github.com:BerriJ/cpptimer.git > /tmp/remotes257564d64e0/BerriJ-rcpptimer-35ca024/inst/include/cpptimer' had > status 128 and error message 'Function not implemented' > root@4163d5544547:/# > exit > > > [2] The "Rcpp-library" vignette John refers to also mentions (IIRC) that > this > is preferable for smaller libraries; its 'corels' example fits that > description. These days other authors also vendor entire applications such > as whole SQL engines: ¯\_(ツ)_/¯ I just updated qlcal on CRAN, it > explicitly > copies the calendaring (subset) from QuantLib as I learned over 20 years > that > users have difficulties with that large library. Tradeoffs. > > -- > 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
