[Rcpp-devel] Distribution of Rcpp codebase

[...]

The only small downsides I see here is that (1) users potentially have to
do more work to include Rcpp* in their packages (although you can just
write an R function to include/update their Rcpp* versions); and that (2)
source packages will be somewhat bigger.


The difference is that if they don't want a new version, they can stick
with the version they have in their package. So when they want newer Rcpp,
they can have it, but they are not forced to do anything when the Rcpp*
team wants to update the codebase.

About 1). We just need to find a good way to propagate newer Rcpp* into a
repo. Maybe through git subtree, git sub modules or something. We can come
up with some tools.

Oh, I see, you mean installing Rcpp* dependent packages from git(hub)
directly. I imagine some people would want to put the headers into their
tree, as ordinary files. Others might want to have it as submodules. For
the latter to work, I imagine you would need to set up some special repo
structure.

Btw. I obviously don't have to tell you, but I want to point it out that
this "snapshotting" is already possible today. I can just take the Rcpp*
headers and put them in my package, and then I don't have to worry about
future changes. This is assuming the package is header-only. With compiled
code it is trickier, because of the name clashes.

So I think, the question is whether to support this with some
infrastructure, e.g. to update the embedded headers, have them as a git
submodule, etc.

About 2). So What ;)

Agreed. CRAN-core might be fussy about it, though, if source packages get
much bigger because of this. Or might be not.

Gabor

[...]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20140407/d3281b10/attachment-0001.html>