[R-pkg-devel] Delays in CRAN Windows Binaries?
Hi All, Just thought that I would check to see if there are any known issues/delays for CRAN in creating R release and devel binaries for Windows for updated packages. It has been four days since I submitted an update and the other binaries were created within a couple of days. The two Windows binaries are the only outstanding updates pending. Thanks! Marc Schwartz __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Delays in CRAN Windows Binaries?
Related to this:
It would be neat to have a dashboard that reports on the current
latency is on the different CRAN "queues" are, e.g. how long is the
average waiting time when submitting a new package ("newbies") until
you get a manual reply or it's on CRAN, submitting an update with all
OK before it hits CRAN, waiting time for building Windows or macOS
binaries, etc. Some, but not all, of this information can already be
guestimated from the info on ftp://cran.r-project.org/incoming/, on
easier on https://lockedata.github.io/cransays/articles/dashboard.html.
I think this could be a great contributor project - it doesn't have to
be hosted by CRAN.
/Henrik
On Wed, Oct 21, 2020 at 11:08 AM Marc Schwartz wrote:
>
> Hi All,
>
> Just thought that I would check to see if there are any known issues/delays
> for CRAN in creating R release and devel binaries for Windows for updated
> packages.
>
> It has been four days since I submitted an update and the other binaries were
> created within a couple of days. The two Windows binaries are the only
> outstanding updates pending.
>
> Thanks!
>
> Marc Schwartz
>
> __
> 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
Re: [R-pkg-devel] Usage of internet resources in examples
Thanks Martin,
I agree that the example should run for a user when calling example() - hence I
am going with a simple try() around the function calls in the examples. I agree
your more sophisticated version has better behaviour, but I don’t want to
clutter the examples with code that might just confuse a user.
Andy
> On Oct 21, 2020, at 12:08 AM, Martin Maechler
> wrote:
>
>> Ben Bolker
>>on Tue, 20 Oct 2020 17:07:10 -0400 writes:
>
>> On 10/20/20 4:51 PM, Gábor Csárdi wrote:
>>> On Tue, Oct 20, 2020 at 9:45 PM Ben Bolker wrote:
>>> [...]
if (testthat::skip_on_cran())
all seem like reasonable solutions.
>>>
>>> I don't think you can use `testthat::skip_on_cran()` for this, it does
>>> not return a logical flag:
>>>
>>> ❯ isTRUE(testthat::skip_on_cran())
>>> Error: Reason: On CRAN
>>>
>>> It only works in testthat tests.
>>>
>>> Gabor
>>>
>>> [...]
>>>
>
>> oh OK, sorry. The guts of the function are (in testthat:::on_cran(),
>> which can't be used because it's not exported)
>
>> !identical(Sys.getenv("NOT_CRAN"), "true")
>
> I still disagree with that part of your recommendations, for this reason:
> I think a "perfect" solution would keep the example(s) running
> fine when the user calls
>
> example()
>
> (hence it is very good recommendation to *not* misuse \dontrun{.} here)
> *and* have the example(.) call *not* stop on error, but (say)
> produce a warning in the case the internet connection isn't
> stable at the time the user calls example(.),
> e.g., myself in a train ride in the Swiss alps ..
>
> Hence, your (Ben's) first two suggestions make more sense to me,
> and I'd clearly favor
>
> try(.)
>
> or possibly slightly more sophsticated versions such as
>
> if(inherits(try({
> ...
> }), "try-error")) warning()
>
> Or then your 2nd suggestion, if(interactive())
> in the case (as it seems here) where the package author
> really wants the user to get an error when the internet
> connection fails.
>
>
> Martin
>
> __
> 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
Re: [R-pkg-devel] Usage of internet resources in examples
> Ben Bolker
> on Tue, 20 Oct 2020 17:07:10 -0400 writes:
> On 10/20/20 4:51 PM, Gábor Csárdi wrote:
>> On Tue, Oct 20, 2020 at 9:45 PM Ben Bolker wrote:
>> [...]
>>> if (testthat::skip_on_cran())
>>>
>>> all seem like reasonable solutions.
>>
>> I don't think you can use `testthat::skip_on_cran()` for this, it does
>> not return a logical flag:
>>
>> ❯ isTRUE(testthat::skip_on_cran())
>> Error: Reason: On CRAN
>>
>> It only works in testthat tests.
>>
>> Gabor
>>
>> [...]
>>
> oh OK, sorry. The guts of the function are (in testthat:::on_cran(),
> which can't be used because it's not exported)
> !identical(Sys.getenv("NOT_CRAN"), "true")
I still disagree with that part of your recommendations, for this reason:
I think a "perfect" solution would keep the example(s) running
fine when the user calls
example()
(hence it is very good recommendation to *not* misuse \dontrun{.} here)
*and* have the example(.) call *not* stop on error, but (say)
produce a warning in the case the internet connection isn't
stable at the time the user calls example(.),
e.g., myself in a train ride in the Swiss alps ..
Hence, your (Ben's) first two suggestions make more sense to me,
and I'd clearly favor
try(.)
or possibly slightly more sophsticated versions such as
if(inherits(try({
...
}), "try-error")) warning()
Or then your 2nd suggestion, if(interactive())
in the case (as it seems here) where the package author
really wants the user to get an error when the internet
connection fails.
Martin
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
