[Rcpp-devel] Distribution of Rcpp codebase
Rainer M Krug
Rainer at krugs.de
Tue Apr 8 11:47:05 CEST 2014
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>
More information about the Rcpp-devel
mailing list