[Rcpp-devel] Distribution of Rcpp codebase

[Rainer M Krug]

Romain François <romain at r-enthusiasts.com> writes:

> Le 8 avr. 2014 à 10:51, Rainer M Krug <Rainer at krugs.de> a écrit :
>
>> Martyn Plummer <plummerm at iarc.fr> writes:
>> 
>>> 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.
>>> 
>>> If you choose some other mechanism, then I suspect that any developer
>>> problems you eliminate will just return as system administration
>>> problems.
>> 
>> I thought I could keep out of this...
>> 
>> rcpp... is so much the core of many packages, that the mechanism of
>> packages really shows its shortcomings, namely the versioning. A
>> different aspect was discussed on the r-devel list some time ago
>> concerning snapshots of CRAN to provide reproducibility.
>> 
>> The part which makes rcpp outstanding from other packages, is that it is
>> used mainly during compilation and not that much during running - that
>> is if I understand the "header only" concept correctly.
>
> Well with the current Rcpp, you still need the runtime for any of the
> functions that are registered here:
> https://github.com/RcppCore/Rcpp/blob/master/src/Rcpp_init.cpp#L85
>
> That’s what I meant earlier when I mentioned job half done. The
> intention of the change in 0.11.0 was to move away from runtime, but
> we did not go far enough.

I must admit, I am not to familiar with rcpp to comment on these
functions, but would it be possible to split Rcpp into headers-only,
i.e. only for compiling and developing, and Rcpp-runtime for runtime?
Because I really think it might make sense to have additional function
at runtime? 


>
>> In contrast, as far as I know, all other packages provide run-time
>> features as well as compile time - and this is what the packages were
>> designed for - and I might say they work quite well. 
>
> I agree. 
>
>> I can see Romain's point (oparticularly the more fine grained control of
>> the developer), but I also understand that Dirk will keep rcpp as a
>> package.
>
> Sure. 
>
>> My question is: would it be possible to combine these two, i.e. have one
>> package, which contains different versions, and to use one command to
>> switch between these? So one would have one package, which will switch
>> between different versions?
>
> I see your point, but I would not want to do that. I can definitely
> foresee a whole new class of issues with this scenario.
>
>> I don't know if this would be possible or a suitable solution?
>> 
>> The other would obviously be to have different versions of rcpp on CRAN,
>> similar to ggplot or oxygen.
>
> I can see this working. 
>
> But there could be Rcpp_0_12_0, Rcpp_0_12_1, etc .. as different
> packages so that developers who want to update their package would
> need to change the version on which they depend.

Well - I would stick with the usual system, that would mean Rcpp_0_12,
Rcpp_0_13, ... and no further fine grained. 


>
> Not sure CRAN would be impressed if I start releasing a new package for each version. 

Agreed. 

>
>> Cheers,
>> 
>> Rainer
>> 
>>> 
>>> 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
>> 
>> -- 
>> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)
>> 
>> Centre of Excellence for Invasion Biology
>> Stellenbosch University
>> South Africa
>> 
>> Tel :       +33 - (0)9 53 10 27 44
>> Cell:       +33 - (0)6 85 62 59 98
>> Fax :       +33 - (0)9 58 10 27 44
>> 
>> Fax (D):    +49 - (0)3 21 21 25 22 44
>> 
>> email:      Rainer at krugs.de
>> 
>> Skype:      RMkrug
>> 
>> PGP: 0x0F52F982
>> _______________________________________________
>> 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
>

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer at krugs.de

Skype:      RMkrug

PGP: 0x0F52F982
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 494 bytes
Desc: not available
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20140408/ab21cc10/attachment.sig>