Romain François <rom...@r-enthusiasts.com> writes: > Le 8 avr. 2014 à 10:51, Rainer M Krug <rai...@krugs.de> a écrit : > >> Martyn Plummer <plumm...@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@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@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: rai...@krugs.de >> >> Skype: RMkrug >> >> PGP: 0x0F52F982 >> _______________________________________________ >> Rcpp-devel mailing list >> Rcpp-devel@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: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982
pgp4smEPxVnEU.pgp
Description: PGP signature
_______________________________________________ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel