[Rcpp-devel] Distribution of Rcpp codebase

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


Thanks to have interest in this discussion. 

Le 7 avr. 2014 à 20:30, Kevin Ushey <kevinushey at gmail.com> a écrit :

> Here's some thoughts, from the perspective of a package developer who
> might want to use Rcpp11.
> 
> One option is to have the Rcpp11 distribution live as a git repository
> within the `inst/include` directory of a developer's package. A
> package developer could clone the repository (or have it track the
> inst/include subdirectory of Rcpp11 -- not sure if that's possible),
> and at their leisure pull the current version, pull a certain tag /
> release, and so on.). Maybe there's something that needs to be in
> .Rbuildignore to ensure the .git repository doesn't get added into the
> built package on R CMD build.
> 
> Some R functions, e.g. useRcpp11(), could be written that, when run in
> the package directory, clones a repository in inst/include/Rcpp, and
> also updates pertinent licensing information (this package uses
> Rcpp11, which is licensing under so-and-so...). Essentially they would
> be nice wrappers to git. Maybe package these as part of an Rcpp11 CRAN
> / GitHub release.

I think git subtree is the right tool. 

> I'm not sure how well a mechanism like this would work for syncing
> across the other Rcpp libraries, e.g. RcppArmadillo, though.

As long as these other are header only, that would be pretty easy. We’d have to diverge them as well as they carry various fastLm, etc ... which really don’t belong there (before the Rcpp police gets involves : I know they will stay). 

> One should expect that packages depending on Rcpp11 will still want to
> be submitted to CRAN, and one potential problem (I know we could say
> 'not our problem', but we should be good citizens) is that, if R-Core
> decides to make an R API change that causes these packages to fail R
> CMD check, it will be more painful for them to accept maintenance
> releases from all these packages.

There are guarantees on R api changes. I don’t see this as an issue. 

> Finally -- we might consider moving this discussion to a new mailing
> list, since I think Rcpp and Rcpp11 are divergent enough that we
> should consider Rcpp-devel for Rcpp-the-package-specific discussion,
> and a different mailing list for Rcpp11 development. Thoughts, Romain?

I though this mailing list was about discussing R and C++, but apparently I was wrong. Fair enough if this is just Rcpp related. Perhaps I’ll leave the mailing list as I’m not that interested in Rcpp anymore. 

Rcpp11 has its own github issues, this I think is enough for now, but sure maybe a new mailing list would be good. 

> On Mon, Apr 7, 2014 at 10:20 AM, Gábor Csárdi <csardi.gabor at gmail.com> wrote:
>> 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. 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
>> 
>> [...]
>> 
>> _______________________________________________
>> Rcpp-devel mailing list
>> Rcpp-devel at lists.r-forge.r-project.org
>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel



More information about the Rcpp-devel mailing list