[R-pkg-devel] Rcpp: how best to include source from another Github repository

[John Clarke]

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 <edd using 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 using 4163d5544547:/# installGithub.r https://github.com/BerriJ/rcpptimer
> Downloading GitHub repo BerriJ/rcpptimer using HEAD
> '/usr/bin/git' clone --depth 1 --no-hardlinks --recurse-submodules
> git using 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.
> git using 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 git using github.com:BerriJ/cpptimer.git
> /tmp/remotes257564d64e0/BerriJ-rcpptimer-35ca024/inst/include/cpptimer' had
> status 128 and error message 'Function not implemented'
> root using 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 | edd using debian.org
>
> ______________________________________________
> R-package-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

	[[alternative HTML version deleted]]