You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm trying check_win_devel() on a package for which I'm not the primary maintainer.
Thus, the default behavior (e-mailing the primary maintainer as pulled from the DESCRIPTION) is not what I need -- I need to specify email= instead to temporarily override the primary maintainer.
My experience would have been much better if this option were made evident to me from the prompt -- the current UI gives 2/3 "no" options and 1 "yes" option, strongly implying that there's no way to avoid using the DESCRIPTION maintainer!
I ran check_win_devel()three times before resigning myself to "OK, I guess we'll have to send the report to the primary maintainer then..."
Only later did I think "Oh, maybe there's an option for setting the email?"
The easiest way for improvement here would be to at least mention the other option in this prompt:
if (interactive() && yesno("Email results to {.strong {email}}?")) {
Even better, IMO, would be a 4th option "4: Choose another maintainer", where we either enter the e-mail directly for this first prompt or as a response to a follow-up prompt.
The text was updated successfully, but these errors were encountered:
Yes I agree your suggestions would be nicer, but require a lot of custom code beyond the current use of the existing multi-purpose yesno() utility. Maybe a compromise would be to alert the user to the email argument if they say "no". That would have shortened your saga to 1 attempt.
Yes I agree your suggestions would be nicer, but require a lot of custom code beyond the current use of the existing multi-purpose yesno() utility. Maybe a compromise would be to alert the user to the email argument if they say "no". That would have shortened your saga to 1 attempt.
that makes sense to me -- it solves the primary issue here which is the current setup distracts the user from the possibility to check if there's an email= argument. And we can leave the more elaborate design as a nice-to-have in case of a refactor down the road that would make it easier to incorporate.
I'm trying
check_win_devel()
on a package for which I'm not the primary maintainer.Thus, the default behavior (e-mailing the primary maintainer as pulled from the DESCRIPTION) is not what I need -- I need to specify
email=
instead to temporarily override the primary maintainer.My experience would have been much better if this option were made evident to me from the prompt -- the current UI gives 2/3 "no" options and 1 "yes" option, strongly implying that there's no way to avoid using the DESCRIPTION maintainer!
I ran
check_win_devel()
three times before resigning myself to "OK, I guess we'll have to send the report to the primary maintainer then..."Only later did I think "Oh, maybe there's an option for setting the email?"
The easiest way for improvement here would be to at least mention the other option in this prompt:
devtools/R/check-win.R
Line 78 in 69d6104
Even better, IMO, would be a 4th option "4: Choose another maintainer", where we either enter the e-mail directly for this first prompt or as a response to a follow-up prompt.
The text was updated successfully, but these errors were encountered: