[R-pkg-devel] [UNCLASSIFIED] Remotes in description when submitting a package until a dependency is fixed

[Bernd . Gruber]

Hi,

I have a package (dartR) that needs to be updated by CRAN (and got a time set 
until a certain date). It depends on a package that is currently showing errors 
in the CRAN results and therefore fails. The maintainer of that package is 
busily trying to rectify the error (as can be seen be repeated submissions in 
the last weeks), but was not able yet to fix it. As we are running out of time 
my approach would be to have a version of the package that fixes it and use 
Remotes: in the description. It runs fine without errors.

In the R-packages book I read the following:

"It's important to note that you should not submit your package to CRAN in the 
intermediate state, meaning with a Remotes field and with a dependency required 
at a version that's not available from CRAN or Bioconductor. For CRAN packages, 
this can only be a temporary development state, eventually resolved when the 
dependency updates on CRAN and you can bump your minimum version accordingly."

So is it okay to submit our package with a remote statement until the 
maintainer of the other package has fixed their issues?

Thanks in advance,
Bernd


==
Dr Bernd Gruber  )/_
 _.--..---"-,--c_
Professor Ecological Modelling  \|..'   ._O__)_
Tel: (02) 6206 3804 ,=._.+   _ \..--( /
Fax: (02) 6201 2328   \\.-''_.-' \ ( \_
Institute for Applied Ecology  `'''   `\__   /\
Faculty of Science and Technology  ')
University of Canberra   ACT 2601 AUSTRALIA
Email: bernd.gru...@canberra.edu.au
WWW: 
bernd-gruber
==

[UC Logo]

[Its time to control your Future. Apply now to study with Australia's fastest 
rising University. *QS, 2022]



The Ngunnawal people are the Traditional Custodians of the ACT where UC's Bruce 
Campus is situated and are an integral and celebrated part of UC's culture. We 
also acknowledge other First Nations Peoples.

Australian Government Higher Education Registered Provider (CRICOS) #00212K. 
TEQSA Provider ID: PRV12003 (Australian University)
Email 
Disclaimer

[UC Facebook][UC Twitter] 
 [UC Instagram] 
 [UC Linkedin] 
 [UC Youtube] 
 [University of Canberra] 


[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] [UNCLASSIFIED] Remotes in description when submitting a package until a dependency is fixed

[Hugh Parsonage]

I think you've misunderstood that excerpt.  By "temporary development
state", it means _between_ CRAN releases; packages in a development
state are not suitable for CRAN, as the policy states:

> CRAN hosts packages of publication quality and is not a development platform.

You'll need to stop depending on that package until it's fixed and the
fix is on CRAN. That said, it looks like it might be relatively
straightforward to disentangle yourself from the package -- just
rewrite the offending example?

On Wed, 16 Nov 2022 at 15:35, Bernd.Gruber  wrote:
>
> Hi,
>
> I have a package (dartR) that needs to be updated by CRAN (and got a time set 
> until a certain date). It depends on a package that is currently showing 
> errors in the CRAN results and therefore fails. The maintainer of that 
> package is busily trying to rectify the error (as can be seen be repeated 
> submissions in the last weeks), but was not able yet to fix it. As we are 
> running out of time my approach would be to have a version of the package 
> that fixes it and use Remotes: in the description. It runs fine without 
> errors.
>
> In the R-packages book I read the following:
>
> "It's important to note that you should not submit your package to CRAN in 
> the intermediate state, meaning with a Remotes field and with a dependency 
> required at a version that's not available from CRAN or Bioconductor. For 
> CRAN packages, this can only be a temporary development state, eventually 
> resolved when the dependency updates on CRAN and you can bump your minimum 
> version accordingly."
>
> So is it okay to submit our package with a remote statement until the 
> maintainer of the other package has fixed their issues?
>
> Thanks in advance,
> Bernd
>
>
> ==
> Dr Bernd Gruber  )/_
>  _.--..---"-,--c_
> Professor Ecological Modelling  \|..'   ._O__)_
> Tel: (02) 6206 3804 ,=._.+   _ \..--( /
> Fax: (02) 6201 2328   \\.-''_.-' \ ( \_
> Institute for Applied Ecology  `'''   `\__   /\
> Faculty of Science and Technology  ')
> University of Canberra   ACT 2601 AUSTRALIA
> Email: bernd.gru...@canberra.edu.au
> WWW: 
> bernd-gruber
> ==
>
> [UC Logo]
>
> [Its time to control your Future. Apply now to study with Australia's fastest 
> rising University. *QS, 2022]
>
>
>
> The Ngunnawal people are the Traditional Custodians of the ACT where UC's 
> Bruce Campus is situated and are an integral and celebrated part of UC's 
> culture. We also acknowledge other First Nations Peoples.
>
> Australian Government Higher Education Registered Provider (CRICOS) #00212K. 
> TEQSA Provider ID: PRV12003 (Australian University)
> Email 
> Disclaimer
>
> [UC Facebook][UC Twitter] 
>  [UC Instagram] 
>  [UC Linkedin] 
>  [UC Youtube] 
>  [University of Canberra] 
> 
>
> [[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

[R-pkg-devel] Too many processes spawned on Windows and Debian, although only 2 cores should be used

[Riko Kelter]

Hello,

I have a short question on the number of processes which are spawned 
during parallelization. My package passes R CMD check –as-cran on MacOS 
and Linux, but the vignettes fail with the following error on Windows 
and Debian:

|--- re-building 'gettingstarted.Rmd' using rmarkdown Quitting from 
lines 121-122 (gettingstarted.Rmd) Error: processing vignette 
'gettingstarted.Rmd' failed with diagnostics: 55 simultaneous processes 
spawned --- failed re-building 'gettingstarted.Rmd'|

The same happens on Debian, where 31 processes are spawned. In all 
vignettes, I followed a stackoverflow thread and included the following 
check for the number of cores on CRAN:

|chk <- Sys.getenv("_R_CHECK_LIMIT_CORES_", "") if (nzchar(chk) && chk 
== "TRUE") { # use 2 cores in CRAN/Travis/AppVeyor num_workers <- 2L } 
else { # use all cores in devtools::test() num_workers <- 
parallel::detectCores() }|

see also 
https://stackoverflow.com/questions/50571325/r-cran-check-fail-when-using-parallel-functions

Link to the files and check results:

https://win-builder.r-project.org/incoming_pretest/brada_1.0_20221115_141147/

Question: Does anyone have a clue why so many processes are spawned on 
Windows / Debian? There should be only 2 processes spawned if I am correct.

PS: Maybe there is a Windows user who can reproduce the 
gettingstarted.Rmd vignette and tell me how many processes are spawned 
on his machine.

PPS: I saw someone recommending to put options(mc.cores=2) at the top of 
each vignette, but I think the above code snippet replaces this.

Thanks for any help, all the best,

Riko

​
[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Too many processes spawned on Windows and Debian, although only 2 cores should be used

[Ivan Krylov]

В Wed, 16 Nov 2022 07:29:25 +0100
Riko Kelter  пишет:

> if (nzchar(chk) && chk == "TRUE") {
>  # use 2 cores in CRAN/Travis/AppVeyor
>  num_workers <- 2L
> }

The check in parallel:::.check_ncores is a bit different:

chk <- tolower(Sys.getenv("_R_CHECK_LIMIT_CORES_", ""))
if (nzchar(chk) && (chk != "false")) # then limit the workers

Unless you actually set _R_CHECK_LIMIT_CORES_=FALSE on your machine
when running the checks, I would perform a more pessimistic check of
nzchar(chk) (without additionally checking whether it's TRUE or not
FALSE), though copy-pasting the check from parallel:::.check_ncores
should also work.

Can we see the rest of the vignette? Perhaps the problem is not with
the check. For example, a piece of code might be implicitly spawning a
new cluster, defaulting to all of the cores instead of num_workers.

>   [[alternative HTML version deleted]]

Unfortunately, the plain text version of your message prepared by your
mailer has all the code samples mangled:
https://stat.ethz.ch/pipermail/r-package-devel/2022q4/008647.html

Please compose your messages to R mailing lists in plain text.

-- 
Best regards,
Ivan

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel