On Sat, Aug 24, 2013 at 9:46 AM, Kasper Daniel Hansen <kasperdanielhan...@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@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel