On 13-08-28 9:00 PM, Kasper Daniel Hansen wrote:
On Wed, Aug 28, 2013 at 3:22 PM, Duncan Murdoch
<[email protected] <mailto:[email protected]>> 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
How does this argument not apply to *all* tests done by CRAN? Should it
stop doing any tests at all, because users can do them if they care?
Duncan Murdoch
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
<[email protected] <mailto:[email protected]>> wrote:
> On 13-08-28 12:29 PM, Marc Schwartz wrote:
>
>>
>> On Aug 28, 2013, at 11:15 AM, Paul Gilbert
<[email protected] <mailto:[email protected]>> 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
>
>
> ________________________________**________________
> [email protected] <mailto:[email protected]> 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]]
________________________________________________
[email protected] <mailto:[email protected]> mailing list
https://stat.ethz.ch/mailman/__listinfo/r-devel
<https://stat.ethz.ch/mailman/listinfo/r-devel>
______________________________________________
[email protected] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
