From hb at biostat.ucsf.edu  Mon Aug 26 21:55:50 2013
From: hb at biostat.ucsf.edu (Henrik Bengtsson)
Date: Mon, 26 Aug 2013 12:55:50 -0700
Subject: [Rd] legitimate use of :::
In-Reply-To: <CAC2h7us=Duy3L8N5H--hfyOx__-Yp+uiYxV7YY6eK==Tisw1Gg@mail.gmail.com>
References: <CANROs4dyoRyjoVHZLs7wDrFrjVX-1zvTTv2i4tBzF3f6Rx-XTA@mail.gmail.com>
	<5215F9BD.5030009@statistik.tu-dortmund.de> <52165F15.1090500@yorku.ca>
	<CABdHhvENvyTD6dPtbQzNaGqgwHNtV86juZh=5F7oBQSPJhO1Rw@mail.gmail.com>
	<CADwqtCNSE=-S9r97WcGL=bKosMnTx6KddPc08Tj_kLNPTN3i+Q@mail.gmail.com>
	<CAJoaRhamc8VRm2DYAKCzQUJA7DO4ypwvP6w_XkDWmCFOAwMDgg@mail.gmail.com>
	<CAC2h7us=Duy3L8N5H--hfyOx__-Yp+uiYxV7YY6eK==Tisw1Gg@mail.gmail.com>
Message-ID: <CAFDcVCQ5iB32tzYjvz6USJsBRWxpVO=L8gp01pN79sfLLFhdmQ@mail.gmail.com>

On Sat, Aug 24, 2013 at 9:46 AM, Kasper Daniel Hansen
<kasperdanielhansen at gmail.com> wrote:
> On Thu, Aug 22, 2013 at 8:27 PM, Peter Meilstrup Using ::: on a package you
> don't control can be more dangerous. For a
>>
>> package author to choose to export a function to the public interface
>> represents at least some assurance that that interface will be stable or
>> slow-moving. But there are no implied assurances about how code in the
>> private namespace might change behind the scenes. I might completely
>> refactor the code and change the behavior of any private function between
>> 0.0.1 releases, but I would not do that for exported functions.
>
>
> This is true (that it could be dangerous), but sometimes, as a package
> author, I am willing to take this risk.  Personally, I don't do this
> lightly, but sometimes there is no way around it, particular if the hidden
> function does some magic in its own NAMESPACE.  It is not all functions
> that one can just easily copy over into you own package.
>
> It is fine to say that the use of ::: should be discouraged, it is another
> thing if it prevents you from submitting to CRAN (which I don't know for
> sure; I thought that Notes were ok?).

Closely related and particularly on which NOTEs are CRAN show stoppers
and which are not:

I find 'R CMD check' extremely useful and I believe it has greatly
improved the quality of R and contributed packages including mine.
The more checks/tests the better.  No doubt about that.   Keeping in
mind the famous statement that "R is not CRAN" (or is it "CRAN is not
R"), and knowing there is great overlap between R core and CRAN team
members, it is still not easy to distinguish between what is R and
what is CRAN and where they're heading.  The CRAN Repository Policy
[http://cran.r-project.org/web/packages/policies.html ; very useful
addition] is very clear on 'R CMD check --as-cran' WARNINGs and
ERRORs, but for NOTEs it leaves room for interpretation.  For
instance, it mentions that package with "significant notes" needs to
be updated, but from experience I'd say it's up to the package
developer to guess what CRAN means by "significant notes".  It also
gives sends the message that there is some leeway for the developer to
publish a package with ("regular"?) NOTEs as long as s/he has
considered their implications [cf. "If there are warnings or notes you
cannot eliminate (for example because you believe them to be spurious)
send an explanatory note as part of your covering email, or as a
comment on the submission form."].   Unfortunately you won't find out
until submission, which seems a waste of time for both the developer
and CRAN.

If CRAN accept certain 'R CMD check --as-cran' NOTEs but not others,
may I propose some kind of mechanism to '--as-cran' that
grep()/grep(invert=TRUE) which NOTEs are significant/non-significant
for CRAN submissions/updates?  That may be too much work to be
exhaustive, but at least the ones that, to CRAN, are obviously
rejected/accepted would be helpful.  With 4700+ packages of CRAN with
lots of daily submissions/updates, the CRAN team has a much better
idea what's accepted or not, than each individual developer.

If it is the case that CRAN consider the majority of the NOTEs to be
"significant", I propose to clarify/be explicit about that in the CRAN
Repository Policy document.

...and finally, thanks to the CRAN team [if they read this] for the
work they put in daily.

/Henrik

PS. I am aware that proposals to CRAN should be sent to CRAN, but it's
useful to have this discussion among R developers before going
one-on-one with CRAN.  If there is an agreement on the above, I'll
send it off to the CRAN team.

>
> Best,
> Kasper
>
>         [[alternative HTML version deleted]]
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



[Rd] legitimate use of :::
Henrik Bengtsson