On 16/05/2019 1:10 p.m., Jennifer Bryan wrote:
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 haven't been involved with CRAN for a couple of years, but for the
year when I was, one thing that really, really pissed us off was a
question like this. Obviously it is better if all functions have
examples. When package authors tried to determine the absolute least
work they could get away with it really wasted our time trying to decide
which side of the line a particular package fell on. We tried to be
consistent, but clearly that would be impossible.
So the answer to your question is: put excellent examples in all of
your help pages, and don't try to find the minimally publishable package.
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.
Impose higher standards on yourself than you think are necessary, and
your packages will be better and will be published faster.
Duncan Murdoch
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> 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> On Behalf
Of Mark van der Loo
Sent: Thursday, 16 May 2019 1:50 AM
To: Jennifer Bryan <jenny.f.br...@gmail.com>
Cc: R Package Development <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>
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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
jstorimer.com%2Fblogs%2Fworkingwithcode%2F7766119-when-to-use-stderr-i
nstead-of-stdout&data=01%7C01%7Chongooi%40microsoft.com%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 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%
2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-devel&data=0
1%7C01%7Chongooi%40microsoft.com%7C6ab84a03dd6048a5160d08d6d94d0
b70%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=eiVhKOo%2F1
JcZuYXyZKLQq2o5Jv0So%2BOebJgbXT%2BLpOw%3D&reserved=0
______________________________________________
R-package-devel@r-project.org mailing list
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fst
at.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-devel&data=01%7C01%7
Chongooi%40microsoft.com%7C6ab84a03dd6048a5160d08d6d94d0b70%7C72f988
bf86f141af91ab2d7cd011db47%7C1&sdata=eiVhKOo%2F1JcZuYXyZKLQq2o5J
v0So%2BOebJgbXT%2BLpOw%3D&reserved=0
[[alternative HTML version deleted]]
______________________________________________
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%7Chon
gooi%40microsoft.com%7C6ab84a03dd6048a5160d08d6d94d0b70%7C72f988bf86f1
41af91ab2d7cd011db47%7C1&sdata=eiVhKOo%2F1JcZuYXyZKLQq2o5Jv0So%2BO
ebJgbXT%2BLpOw%3D&reserved=0
[[alternative HTML version deleted]]
______________________________________________
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
[[alternative HTML version deleted]]
______________________________________________
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
