[Rcpp-devel] Distribution of Rcpp codebase

Romain François romain at r-enthusiasts.com
Mon Apr 7 20:19:13 CEST 2014


Le 7 avr. 2014 à 19:20, Gábor Csárdi <csardi.gabor at gmail.com> a écrit :

> On Mon, Apr 7, 2014 at 9:20 AM, Romain François <romain at r-enthusiasts.com> wrote:
> [...]
>> 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.

Having the files into the client package is what I meant. This way, the developer of the package is in control of what version is used. The challenge is how to make it easy.

> 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.

I think git subtree gives something close to what I mean. But obviously someone could just copy the files manually, it would just be a matter of copying the inst/include directory. 

> 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.

Good luck doing that with current Rcpp. Many functions are compiled into the shared library shipped with the package. It is not linking as it used to do it, which is the big win of 0.11.0, but there is still a library. 

Many of these functions go through the namespace of the Rcpp package, etc … so you could snapshot Rcpp, but it would definitely not be easy at all. 

> 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. 

This is a drop of water in the ocean of CRAN packages. I think the benefit would outweigh this quite easily. 

In any case, not gonna happen, at least not with "Rcpp". 

Romain

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


More information about the Rcpp-devel mailing list