On Wed, Aug 28, 2013 at 3:22 PM, Duncan Murdoch <murdoch.dun...@gmail.com>wrote:
> On 28/08/2013 3:06 PM, Kasper Daniel Hansen wrote: > >> My point of view is that if you have a core package where you need access >> to "hidden" functions for making a plugin, you should probably export >> these >> hidden functions in the first place. Chances are that if you need access >> to these hidden functions (for expert use), other (expert) users might >> want >> access as well, so take the time to export and document it. >> >> I want to use ::: specifically for the case where I have no control over >> the other package. >> > > And as a potential user of your package, I don't want you to use ::: if > you don't have control over the other package, because its author might > unwittingly change it in a way that causes me to get incorrect results. > Perhaps you have heard of the concept of "testing". R actually has good testing facilities (if you include add-on packages) and these facilities are very helpful in checking whether the answers provided by a package are correct. /sarcasm off And btw. nothing guarantees that the output of an exported function does not change when the package version change. Only testing can help you here. I don't know if CRAN re-checks a package if dependencies change, but obviously it ought to, from a software validity point of view. Best, Kasper > If you want to use :::, go ahead, just don't put your package on CRAN, > where I get most of my packages. Then we'll both be happy. > > Duncan Murdoch > >> >> Best, >> Kasper >> >> >> >> >> On Wed, Aug 28, 2013 at 2:50 PM, Paul Gilbert <pgilbert...@gmail.com> >> wrote: >> >> > On 13-08-28 12:29 PM, Marc Schwartz wrote: >> > >> >> >> >> On Aug 28, 2013, at 11:15 AM, Paul Gilbert <pgilbert...@gmail.com> >> wrote: >> >> >> >> I have a package (TSdbi) which provides end user functions that I >> >>> export, and several utilities for plugin packages (e.g. TSMySQL) that >> I do >> >>> not export because I do not intend them to be exposed to end users. I >> call >> >>> these from the plugin packages using TSdbi::: but that now produces >> a note >> >>> in the checks: >> >>> >> >>> * checking dependencies in R code ... NOTE >> >>> Namespace imported from by a ::: call: TSdbi >> >>> See the note in ?`:::` about the use of this operator. :: should be >> >>> used rather than ::: if the function is exported, and a package >> >>> almost never needs to use ::: for its own functions. >> >>> >> >>> Is there a preferred method to accomplish this in a way that does not >> >>> produce a note? >> >>> >> >>> Thanks, >> >>> Paul >> >>> >> >> >> >> >> >> >> >> Paul, >> >> >> >> See this rather lengthy discussion that occurred within the past week: >> >> >> >> https://stat.ethz.ch/****pipermail/r-devel/2013-August/** >> **067180.html<https://stat.ethz.ch/**pipermail/r-devel/2013-August/**067180.html> >> <https://stat.**ethz.ch/pipermail/r-devel/**2013-August/067180.html<https://stat.ethz.ch/pipermail/r-devel/2013-August/067180.html> >> > >> >> >> >> >> Regards, >> >> >> >> Marc Schwartz >> >> >> > >> > I did follow the recent discussion, but no one answered the question "Is >> > there a preferred method to accomplish this?" (I suppose the answer is >> that >> > there is no other way, given that no one actually suggested anything >> else.) >> > Most of the on topic discussion in that thread was about how to subvert >> the >> > CRAN checks, which is not what I am trying to do and was also pointed >> out >> > as a bad idea by Duncan. The substantive response was >> > >> > >r63654 has fixed this particular issue, and R-devel will no longer >> > >warn against the use of ::: on packages of the same maintainer. >> > > >> > >Regards, >> > >Yihui >> > >> > but that strikes me as a temporary work around rather than a real >> > solution: suppose plugins are provided by a package from another >> maintainer. >> > >> > Since CRAN notes have a habit of becoming warnings and then errors, it >> > seems useful to identify the preferred legitimate approach while this is >> > still a note. That would save work for both package developers and CRAN >> > maintainers. >> > >> > My thinking is that there is a need for a NAMESPACE directive something >> > like limitedExport() that allows ::: for identified functions without >> > provoking a CRAN complaint when packages use those functions. But there >> may >> > already be a better way I don't know about. Or perhaps the solution is >> to >> > split the end user functions and the utilities for plugin packages into >> two >> > separate packages? >> > >> > Paul >> > >> > >> > ______________________________****________________ >> > R-devel@r-project.org mailing list >> > https://stat.ethz.ch/mailman/****listinfo/r-devel<https://stat.ethz.ch/mailman/**listinfo/r-devel> >> <https://**stat.ethz.ch/mailman/listinfo/**r-devel<https://stat.ethz.ch/mailman/listinfo/r-devel> >> > >> > >> >> [[alternative HTML version deleted]] >> >> >> >> >> ______________________________**________________ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/**listinfo/r-devel<https://stat.ethz.ch/mailman/listinfo/r-devel> >> > > [[alternative HTML version deleted]]
______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
