search

r-lib / devtools

Tools to make an R developer's life easier
https://devtools.r-lib.org
Other
2.37k stars 755 forks source link

check_win_devel interface is "too cute" #2520

Open MichaelChirico opened 1 year ago

MichaelChirico commented 1 year ago

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:

https://github.com/r-lib/devtools/blob/69d610414c69748d7b5bbe7d890e228bdb5b18ff/R/check-win.R#L78

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.

jennybc commented 8 months ago

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.

MichaelChirico commented 8 months ago

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.

Thanks!