For what it's worth, I recently submitted a new package that was initially refused (with comments) by CRAN. I updated number of them accordingly, but there were a few that with good reasons I could not change. I explained this in the comments when uploading a new version and it got accepted. So I don't see the problem.
(The case here was a use of \dontrun{}. I had to switch an example off because a warning was thrown which would upset R CMD check. But demonstrating the warning was exactly the point of the example.) All this aside. I think it is extremely unethical to publish privately sent CRAN emails on GH, including personal details such as name and e-mail address of the sender without their explicit consent. Best, Mark On Wed, May 15, 2019 at 4:44 PM Jennifer Bryan <jenny.f.br...@gmail.com> wrote: > Hello, > > Since this has turned into a worldwide code review, I will briefly address > that, then reiterate the point of the original message. > > I am working on an initial release of a package. It reveals information to > a user, sometimes in a print method-y way, sometimes in more of a verbose / > debugging way that is under control of a documented option, which defaults > to "off" or "quiet". For now, I have chosen to send all of this output > through a single functions that, yes, uses cat(). I went this direction for > an initial release to keep the package simple and accumulate some user > experience. If the "debugging mode" proves to be useful, I will rework it, > possibly using UI functionality that I believe our group might release in > the future. Rest assured, I understand cat() vs message() and the various > tradeoffs. I made mine and it is my impression that package maintainers > have this level of freedom. > > The real point is: the currenrt CRAN submission process is designed for > one-way communication and there's no guarantee of continuity of reviewer. > If this type of implementation review is going to happen, it seems that > many aspects of the process would need to change, to make sure these new > standards are applied consistently to every submission and that existing > package are brought up to current standards. > > To clarify something for Joris, I am not aware of any special channel of > communication or influence between CRAN and the R Foundation (of which I am > also a member). I think this is an aspect of CRAN vs R Foundation (vs R > Core even) that is unclear to many. These entities operate quite > independently, except for the fact that specific people belong to more than > one. So RF members interact with CRAN the same way as any other of member > of the community. > > -- Jenny > > On Wed, May 15, 2019 at 6:43 AM Jim Hester <james.f.hes...@gmail.com> > wrote: > > > Sorry first sentence should read > > > > I agree that `message()` is ideally preferred, precisely because > > of the reasons Martin stated, it is easily controlled by the user. > > > > On Wed, May 15, 2019 at 9:41 AM Jim Hester <james.f.hes...@gmail.com> > > wrote: > > > > > > I agree that `message()` is in an ideally preferred, precisely because > > > of the reasons Martin stated, it is easily controlled by the user. > > > > > > Unfortunately, in the real world, the windows R gui console and > > > RStudio (which copied behavior) color messages, and anything on stderr > > > in fact, in red, which confuses most users who are trained to treat > > > messages in red as errors. > > > > > > This also makes using colored output (where available) more > > > challenging when using `message()`. You either have to accept the > > > text as red, or unconditionally change the text color to black or > > > similar, which can then be unreadable if the user is using a dark > > > color theme. > > > > > > Jenny is an experienced package developer. She knew this tradeoff and > > > the use of `cat()` in gargle was deliberate choice in an imperfect > > > world. She did not make this decision out of ignorance of a better > > > way. > > > > > > However there is no way for Jenny or any other package developers to > > > have a dialog during a CRAN submission, the communication is only in > > > one direction, if she resubmits explaining her rationale for the > > > choice she may not even have the same reviewer the next time. > > > > > > Bioconductor seems to have a much better review process for > > > submissions, with real dialog between the reviewer and package author, > > > perhaps CRAN can learn from that process and improve the submission > > > experience in the future. > > > > > > Jim > > > > > > On Wed, May 15, 2019 at 7:41 AM Martin Morgan <mtmorgan.b...@gmail.com > > > > wrote: > > > > > > > > message() / warning() / stop() write to stderr whereas print() / > cat() > > write (by default) to stdout. Even without being able to suppress > messages, > > it is well-established practice (the story is that this is the reason why > > 'stderr' was introduced into unix, > > > https://www.jstorimer.com/blogs/workingwithcode/7766119-when-to-use-stderr-instead-of-stdout > > ) to separate diagnostic messages from program output. I agree that > gargle > > (in particular, and packages in general, given the theme of this mailing > > list) would be a better package if it used message() where it now uses > > cat(). > > > > > > > > Martin > > > > > > > > On 5/15/19, 5:04 AM, "R-package-devel on behalf of Joris Meys" < > > r-package-devel-boun...@r-project.org on behalf of joris.m...@ugent.be> > > wrote: > > > > > > > > 2) Where cat() is used in gargle, message() is a better option > for > > the > > > > following reason: > > > > > > > > > myfun <- function(){cat("Yes");message("No")} > > > > > suppressMessages(myfun()) > > > > Yes > > > > > > > > > > > > ______________________________________________ > > > > R-package-devel@r-project.org mailing list > > > > https://stat.ethz.ch/mailman/listinfo/r-package-devel > > > > ______________________________________________ > > R-package-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-package-devel > > > > [[alternative HTML version deleted]] > > ______________________________________________ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > [[alternative HTML version deleted]] ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel