[Rd] ':::' call

Mark.Bravington at csiro.au Mark.Bravington at csiro.au
Thu Aug 29 01:14:27 CEST 2013 

<< Extracted from email trail below >>

> 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.
> 
> 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.
> 

Fine. BTW, when will CRAN be removing the C(omprehensive) from its name?

CRAN can never offer any guarantee that code works properly. Lots of code on CRAN doesn't, that's why packages have bug-fix releases all the time. And packages sometimes change the functionality even of functions that they *do* export. I certainly don't blindly trust stuff I download from CRAN; code aside, lots of it has excruciating documentation which hardly inspires faith. Nor do I blame CRAN for hosting bad code. CRAN is just a library; libraries are not responsible for the content of the books they hold.

With respect specifically to ::: : to guard against functionality changes of the type mentioned, B just needs to use a strict version check on A's package in the NAMESPACE. When A updates on CRAN, B will realize that the new version needs to be checked (because B's package will refuse to load on systems using the new version of A), and B can check functionality and amend their version check.

Adding yet more options about limited exports etc is not a good idea, I think. R's structure is REALLY complicated, particularly when it comes to packages. There is already too much stuff, too many different ways to do things. That is probably one reason why there is so much confusion and indeed so many bad choices from maintainers. Adding yet more techno-fixes is liable to be counterproductive.

Still in the case of :::, I agree with Yihui Xie that CRAN should not bother worrying about it. A Note would be OK if it weren't that Notes have a nasty habit of somehow turning into Warnings. In that respect: why not just have a separate package that has all sort of checks that anyone might ever want (I find most of them useless, but I know others like them), but that is independent of CRAN checks?

More generally, while the principles that CRAN espouses seemed OK to me last time I checked (eg  packages shouldn't mess each other up), the same is not true for the approach CRAN takes to them. The plethora of checks makes the whole thing legalistic: the criterion becomes not "is this package any good?" but "does it pass checks AA-ZZ?" So, for a maintainer with very limited time for arguments and who knows their own code and is well aware that the CRAN checks produce lots of False Positives and also False Negatives (there is lots of bad code out there...), it's hardly surprising if there is every temptation to just pop in a workaround.

If there was a much tighter, and well-explained, set of checks, then I reckon there would be fewer workarounds overall (because of a cultural shift, not just in terms of superfluous checks that have been removed) and there wouldn't be the need for lengthy dialogs between maintainers and CRAN. Notwithstanding the enormous efforts that the CRAN people put in (whoever they may be...): CRAN might be better off working with human nature(s), not against it.

bye
Mark

-- 
Mark Bravington
CSIRO Mathematical & Information Sciences
Marine Laboratory
Castray Esplanade
Hobart 7001
TAS

ph (+61) 3 6232 5118
fax (+61) 3 6232 5012
mob (+61) 438 315 623
 

> -----Original Message-----
> From: r-devel-bounces at r-project.org 
> [mailto:r-devel-bounces at r-project.org] On Behalf Of Duncan Murdoch
> Sent: Thursday, 29 August 2013 5:22 AM
> To: Kasper Daniel Hansen
> Cc: Marc Schwartz; R-devel at r-project.org; Paul Gilbert
> Subject: Re: [Rd] ':::' call
> 
> 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.
> 
> 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 
> <pgilbert902 at gmail.com> wrote:
> >
> > > On 13-08-28 12:29 PM, Marc Schwartz wrote:
> > >
> > >>
> > >> On Aug 28, 2013, at 11:15 AM, Paul Gilbert 
> <pgilbert902 at 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>
> > >>
> > >> 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 at 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 at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

More information about the R-devel mailing list