--- Begin Message ---
I don’t think they check _every_ help page for examples. My assumption would be
that if the main functionality of the package is covered, then functions that
are clearly ancillary, or whose usage is obvious, get a pass.
Another reason for cloud-related packages to mark things as \dontrun (as
opposed to \donttest) would be if they deploy resources that have an associated
cost. You probably don’t want to be charged 50 bucks, or whatever, for
deploying a compute cluster just by running example().
From: Jennifer Bryan <jenny.f.br...@gmail.com>
Sent: Friday, 17 May 2019 3:10 AM
To: Hong Ooi <hong...@microsoft.com>
Cc: R Package Development <r-package-devel@r-project.org>
Subject: Re: [R-pkg-devel] CRAN student assistants
Thanks for the excellent comparable package, Hong.
Today's rejection of gargle instructs me to use \donttest{} instead of
\dontrun{}. Most of the affected functions create, load, and/or refresh service
account tokens and OAuth2 credentials. I see that \dontrun{} is used in
AzureAuth, which does seem more appropriate and is what I did. My impression is
that \donttest{} code is still run under some circumstances. Perhaps this is
another good topic for discussion, now that we've worked through cat() vs
message().
It seems like you've also got a few functions without examples at all (e.g.,
format_auth_header(), AzureR_dir()). How does this get through CRAN review?
When is that OK and when is it not?
I would simply like to understand the standards, so that I can impose them on
myself and go through fewer submissions. Maybe we could even automate some of
those checks. That would reduce workload all around.
I've taken your advice to reply via email with full explanation and cc others
at CRAN. Maybe this will also lead to speedy resolution with no fuss.
-- Jenny
On Wed, May 15, 2019 at 2:18 PM Hong Ooi
<hong...@microsoft.com<mailto:hong...@microsoft.com>> wrote:
I had a similar experience with a couple of my package updates needing changes.
The background is that I have a family of packages for talking to Microsoft's
Azure cloud service from R, and my examples are all marked \dontrun because
they need an Azure subscription to work. This had previously been cleared with
Uwe Ligges, but I guess the other CRAN reviewers weren't aware of this.
In both cases, replying to the CRAN email and cc'ing Uwe resolved the issue
quickly and without fuss.
-----Original Message-----
From: R-package-devel
<r-package-devel-boun...@r-project.org<mailto:r-package-devel-boun...@r-project.org>>
On Behalf Of Mark van der Loo
Sent: Thursday, 16 May 2019 1:50 AM
To: Jennifer Bryan <jenny.f.br...@gmail.com<mailto:jenny.f.br...@gmail.com>>
Cc: R Package Development
<r-package-devel@r-project.org<mailto:r-package-devel@r-project.org>>
Subject: Re: [R-pkg-devel] CRAN student assistants
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<mailto: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<mailto: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<mailto: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<mailto: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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> jstorimer.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fjstorimer.com&data=02%7C01%7Chongooi%40microsoft.com%7C991f01a501964ef9e6da08d6da21834c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636936234812492914&sdata=QE2RboDg7ewRBLCrGNtjVOY7ashqSq6zkuFr0PVbOJE%3D&reserved=0>%2Fblogs%2Fworkingwithcode%2F7766119-when-to-use-stderr-i
> nstead-of-stdout&data=01%7C01%7Chongooi%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7Chongooi%40microsoft.com%7C991f01a501964ef9e6da08d6da21834c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636936234812502913&sdata=3pYd5bkHPUe6OCEbKJqTgf1E1hPN1mrk8Mm4A8HFuxw%3D&reserved=0>%7C6ab84a03
> dd6048a5160d08d6d94d0b70%7C72f988bf86f141af91ab2d7cd011db47%7C1&sd
> ata=8%2F6BhGQWQqy7OOrjw4gaDRuYfPgYIdEoLEpTl6Q4hgQ%3D&reserved=0
> > ) 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<mailto:r-package-devel-boun...@r-project.org>
> > on behalf of
> > joris.m...@ugent.be<mailto: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<mailto:R-package-devel@r-project.org>
> > > > mailing list
> > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%25>
> > > > 2Fstat.ethz.ch<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F2Fstat.ethz.ch&data=02%7C01%7Chongooi%40microsoft.com%7C991f01a501964ef9e6da08d6da21834c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636936234812502913&sdata=jE%2BQDu7dKhXEc85FDAcvkNvT%2Bgkog2fEIUcbADuuwjc%3D&reserved=0>%2Fmailman%2Flistinfo%2Fr-package-devel&data=0
> > > > 1%7C01%7Chongooi%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7Chongooi%40microsoft.com%7C991f01a501964ef9e6da08d6da21834c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636936234812512906&sdata=cKvVlByLzHzPzIef6vaZvh5qFsRrCnc%2Fa3RC61A6raI%3D&reserved=0>%7C6ab84a03dd6048a5160d08d6d94d0
> > > > b70%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=eiVhKOo%2F1
> > > > JcZuYXyZKLQq2o5Jv0So%2BOebJgbXT%2BLpOw%3D&reserved=0
> >
> > ______________________________________________
> > R-package-devel@r-project.org<mailto:R-package-devel@r-project.org> mailing
> > list
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fst
> > at.ethz.ch<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fat.ethz.ch&data=02%7C01%7Chongooi%40microsoft.com%7C991f01a501964ef9e6da08d6da21834c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636936234812512906&sdata=eNbXlC5Zc58m07DVQCbU2p7E3gnLj8TeuCKE2GBjB%2B4%3D&reserved=0>%2Fmailman%2Flistinfo%2Fr-package-devel&data=01%7C01%7
> > Chongooi%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7Chongooi%40microsoft.com%7C991f01a501964ef9e6da08d6da21834c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636936234812512906&sdata=cKvVlByLzHzPzIef6vaZvh5qFsRrCnc%2Fa3RC61A6raI%3D&reserved=0>%7C6ab84a03dd6048a5160d08d6d94d0b70%7C72f988
> > bf86f141af91ab2d7cd011db47%7C1&sdata=eiVhKOo%2F1JcZuYXyZKLQq2o5J
> > v0So%2BOebJgbXT%2BLpOw%3D&reserved=0
> >
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> R-package-devel@r-project.org<mailto:R-package-devel@r-project.org> mailing
> list
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat
> .ethz.ch<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fethz.ch&data=02%7C01%7Chongooi%40microsoft.com%7C991f01a501964ef9e6da08d6da21834c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636936234812522901&sdata=6pIehcndENEMdd8%2FyTWNtD0vec5lC2sufm1KjgFhQX0%3D&reserved=0>%2Fmailman%2Flistinfo%2Fr-package-devel&data=01%7C01%7Chon
> gooi%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7Chongooi%40microsoft.com%7C991f01a501964ef9e6da08d6da21834c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636936234812522901&sdata=4NLlVLB2qLm0Lt08DRv5mABLfncaZaDfanCjijtuhDI%3D&reserved=0>%7C6ab84a03dd6048a5160d08d6d94d0b70%7C72f988bf86f1
> 41af91ab2d7cd011db47%7C1&sdata=eiVhKOo%2F1JcZuYXyZKLQq2o5Jv0So%2BO
> ebJgbXT%2BLpOw%3D&reserved=0
>
[[alternative HTML version deleted]]
______________________________________________
R-package-devel@r-project.org<mailto:R-package-devel@r-project.org> mailing list
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-devel&data=01%7C01%7Chongooi%40microsoft.com%7C6ab84a03dd6048a5160d08d6d94d0b70%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=eiVhKOo%2F1JcZuYXyZKLQq2o5Jv0So%2BOebJgbXT%2BLpOw%3D&reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-devel&data=02%7C01%7Chongooi%40microsoft.com%7C991f01a501964ef9e6da08d6da21834c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636936234812532893&sdata=u77oBbnued1bYd9a825nzbr4%2BTfF6hwDCaVkATv9tc8%3D&reserved=0>
[[alternative HTML version deleted]]
--- End Message ---
