[Rcpp-devel] Distribution of Rcpp codebase

Kevin Ushey kevinushey at gmail.com
Mon Apr 7 20:30:02 CEST 2014


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'm not sure how well a mechanism like this would work for syncing
across the other Rcpp libraries, e.g. RcppArmadillo, though.

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.

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?

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