[Rcpp-devel] Distribution of Rcpp11 codebase

[Martyn Plummer]

On Tue, 2014-04-08 at 10:48 +0200, Romain François wrote:
> Hello Martyn, 
> 
> Thanks for joining the discussion; 
> 
> Le 8 avr. 2014 à 10:36, Martyn Plummer <plummerM at iarc.fr> a écrit :
> 
> > And another 2 cents from me.
> > 
> > A package is the basic unit of functionality in R. Whatever
> > functionality you are providing, I think a package is the best way to
> > deliver it. There is a well developed framework for versioning,
> > dependency resolution, testing, and distribution.
> 
> I definitely agree with you, as far of distributing R code is concerned, an R package is ideal. 
> 
> I no longer think that an R package is the right distribution vessel for a header only C++ library. 
> 
> > If you choose some other mechanism, then I suspect that any developer
> > problems you eliminate will just return as system administration
> > problems.
> 
> I understand that. The way Rcpp11 is structured, the developer will have the choice between: 
>  - using the codebase from Rcpp11, whatever version that is, by just doing a LinkingTo: Rcpp11. 
>  - snapshot Rcpp11 into their package. 
> 
> I will not enforce one or the other. People will have the choice of which problem they’d rather have. 
> 
> With Rcpp, there is no such choice. 

But different people will experience those problems. So the choice is
not just which kind of problem you want but who will experience it.

Example 1. Quality Assurance on CRAN. If CRAN package authors copy and
paste your code into their packages then there is no longer a single
reference point for QA problems, nor a simple way of propagating bug
fixes into the client packages. We have been here before with the
MCMCpack package, parts of which were were copied and pasted into many
other packages. So when there were QA problems with the code, this had
to be addressed multiple times by different authors.

Example 2. Namespace pollution.  As you know, there is a weakness in the
design of dynamic libraries on Linux. There is essentially a flat
namespace and any symbol may be overwritten by another dynamically
loaded module.

http://www.macieira.org/blog/2012/01/sorry-state-of-dynamic-libraries-on-linux/

Windows DLLs do not have this problem.

You may free the package authors from having to keep track of the API,
but a user who loads two Rcpp11-based packages based on different API
versions risks getting a big surprise.  Again, we've been here before
when Duncan Murdoch discovered that the "Node" class in his package was
getting mixed up with the "Node" class in another.

Martyn

 
> Romain
> 
> > Martyn
> > 
> > On Tue, 2014-04-08 at 10:12 +0200, Xavier Robin wrote:
> >> My 2 cents...
> >> 
> >> On 07/04/14 10:12, Romain François wrote:
> >>> It would also mean many copies of the same code base. To which I’m thinking: so what.
> >> No, it will mean many copies of /many different and mostly outdated/ 
> >> code bases.
> >> You can count on me to forget to git pull next time I update my package.
> >> 
> >> What about something like the BH package that contains the boost 
> >> headers? I'm using it in a project I'm working on, and just use a 
> >> LinkingTo declaration with something in Makevars.
> >> Of course ideally it would be in a build-depends type of declaration so 
> >> it isn't pulled during binary installs.
> >> 
> >> Xavier
> >> 
> >> _______________________________________________
> >> 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
> > 
> > _______________________________________________
> > 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
>