[R-pkg-devel] winUCRT failures
The current CRAN release of rgl fails on winUCRT because of missing dependencies: 'htmlwidgets', 'htmltools', 'knitr', 'jsonlite', 'shiny', 'magrittr', 'crosstalk', 'manipulateWidget'. Tracing `htmlwidgets` shows it also fails because of missing dependencies: 'htmltools', 'jsonlite', 'yaml' and 'htmltools' fails because of missing dependencies 'digest', 'base64enc', 'rlang' but 'digest' only gets a warning (congratulations, Dirk!), 'base64enc' gets a NOTE (hurray Simon!). 'rlang' is failing a test because of a missing suggested dependency on 'glue'. At that point I stopped searching. Does anyone have a list of packages that actually need fixes? I'd like to help those maintainers with the necessary updates. Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Cannot reproduce errors of archived CRAN package
All,
I was just informed that the {targets} package was archived.
Version 0.4-1 is still failing on macOS so it and tarchetypes have been
> archived.
> A recheck on my own Intel Mac today gives the same check ERRORs as
> reported on the CRAN results page.
> Do not submit again without reproducing this error and confirming it has
> been corrected.
The CRAN check errors (all unique to {targets} version 0.4.1) are at
https://cran-archive.r-project.org/web/checks/2021/2021-04-25_check_results_targets.html,
and I have been unable to reproduce them. I tried a fresh installation of R
4.0.2 and packages on my own Intel Mac, as well as GitHub Actions and both
Mac builds at https://builder.r-hub.io/. All those checks pass.
The error is somehow related to a very simple internal R6 class:
https://github.com/ropensci/targets/blob/4deba948b8d6ecf82511a5a58b1eb9a0addcf2bd/R/class_config.R.
The elusive failing tests are ostensibly in
https://github.com/ropensci/targets/blob/4deba948b8d6ecf82511a5a58b1eb9a0addcf2bd/tests/testthat/test-class_config.R,
but they always pass for me.
Will
[[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] winUCRT failures
On 25/04/2021 8:49 a.m., Duncan Murdoch wrote: The current CRAN release of rgl fails on winUCRT because of missing dependencies: 'htmlwidgets', 'htmltools', 'knitr', 'jsonlite', 'shiny', 'magrittr', 'crosstalk', 'manipulateWidget'. Tracing `htmlwidgets` shows it also fails because of missing dependencies: 'htmltools', 'jsonlite', 'yaml' and 'htmltools' fails because of missing dependencies 'digest', 'base64enc', 'rlang' but 'digest' only gets a warning (congratulations, Dirk!), 'base64enc' gets a NOTE (hurray Simon!). 'rlang' is failing a test because of a missing suggested dependency on 'glue'. At that point I stopped searching. Does anyone have a list of packages that actually need fixes? I'd like to help those maintainers with the necessary updates. I still haven't found any of the packages at the very root of this cascade of errors, but I've submitted patches to rlang, glue, and magrittr that should allow them to have less severe check issues even if some of their suggested dependencies are missing. What I haven't tried to do is check any of them if *none* of the suggested packages is available. Packages should still build and check without ERRORs in this case, though I'd expect NOTEs and/or WARNINGs. This is an old issue: what packages should be present during CRAN checks? Currently CRAN tries to check with everything present; perhaps it should also try to check with the minimal set. Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] winUCRT failures
On 25 April 2021 at 11:14, Duncan Murdoch wrote: | What I haven't tried to do is check any of them if *none* of the | suggested packages is available. Packages should still build and check | without ERRORs in this case, though I'd expect NOTEs and/or WARNINGs. | | This is an old issue: what packages should be present during CRAN | checks? Currently CRAN tries to check with everything present; perhaps | it should also try to check with the minimal set. I last wrote about that four years ago under the title "Suggests != Depends" http://dirk.eddelbuettel.com/blog/2017/03/22#suggests_is_not_depends Of course, nothing changed. So when helping a R Core member last weekend by checking his package against just over 1000 reverse dependencies, I again had to manually wade through dozens of false errors of packages failing tests when packages they did NOT declare a dependency on were used unconditionally. That is still a very clear error to me, but I no longer expect these windmills will ever stop turning. Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Cannot reproduce errors of archived CRAN package
On reflection, I strongly suspect the errors come from the way I was using
file modification time stamps to manage a user-side configuration file.
{targets} was using a time stamp to decide whether it needs to read the
file, but the precision of time stamps varies from system to system. I
implemented a workaround that avoids time stamps.
On Sun, Apr 25, 2021 at 10:45 AM Will L wrote:
> All,
>
>
> I was just informed that the {targets} package was archived.
>
> Version 0.4-1 is still failing on macOS so it and tarchetypes have been
>> archived.
>> A recheck on my own Intel Mac today gives the same check ERRORs as
>> reported on the CRAN results page.
>> Do not submit again without reproducing this error and confirming it has
>> been corrected.
>
>
> The CRAN check errors (all unique to {targets} version 0.4.1) are at
> https://cran-archive.r-project.org/web/checks/2021/2021-04-25_check_results_targets.html,
> and I have been unable to reproduce them. I tried a fresh installation of R
> 4.0.2 and packages on my own Intel Mac, as well as GitHub Actions and both
> Mac builds at https://builder.r-hub.io/. All those checks pass.
>
> The error is somehow related to a very simple internal R6 class:
> https://github.com/ropensci/targets/blob/4deba948b8d6ecf82511a5a58b1eb9a0addcf2bd/R/class_config.R.
> The elusive failing tests are ostensibly in
> https://github.com/ropensci/targets/blob/4deba948b8d6ecf82511a5a58b1eb9a0addcf2bd/tests/testthat/test-class_config.R,
> but they always pass for me.
>
> Will
>
--
wlandau.github.io
linkedin.com/in/wlandau
github.com/wlandau
[[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] winUCRT failures
On 25/04/2021 11:35 a.m., Dirk Eddelbuettel wrote: On 25 April 2021 at 11:14, Duncan Murdoch wrote: | What I haven't tried to do is check any of them if *none* of the | suggested packages is available. Packages should still build and check | without ERRORs in this case, though I'd expect NOTEs and/or WARNINGs. | | This is an old issue: what packages should be present during CRAN | checks? Currently CRAN tries to check with everything present; perhaps | it should also try to check with the minimal set. I last wrote about that four years ago under the title "Suggests != Depends" http://dirk.eddelbuettel.com/blog/2017/03/22#suggests_is_not_depends Of course, nothing changed. So when helping a R Core member last weekend by checking his package against just over 1000 reverse dependencies, I again had to manually wade through dozens of false errors of packages failing tests when packages they did NOT declare a dependency on were used unconditionally. That is still a very clear error to me, but I no longer expect these windmills will ever stop turning. I agree it's an error. Back when we had one of those discussions it seemed too resource-intensive to do both kinds of tests, and it's much easier to do the "install everything" tests if you are always working with a fixed library. Nowadays I think it's easier to run the tests on a VM that has exactly the packages you specify, so people have less excuse not to do that on their own. I have a Github "workflow" here that does it for rgl: https://github.com/dmurdoch/rgl/actions/workflows/R-CMD-nosoft-check.yml BTW, I've just submitted another patch, this time for the usethis package, which added "Suggests: testthat" and then used testthat unconditionally. That won't help any other existing packages, but if it is accepted it might help in the future. Duncan __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] winUCRT failures
On 25 April 2021 at 12:27, Duncan Murdoch wrote: | On 25/04/2021 11:35 a.m., Dirk Eddelbuettel wrote: | > I last wrote about that four years ago under the title "Suggests != Depends" | > http://dirk.eddelbuettel.com/blog/2017/03/22#suggests_is_not_depends | > | > Of course, nothing changed. | > | > So when helping a R Core member last weekend by checking his package against | > just over 1000 reverse dependencies, I again had to manually wade through | > dozens of false errors of packages failing tests when packages they did NOT | > declare a dependency on were used unconditionally. That is still a very clear | > error to me, but I no longer expect these windmills will ever stop turning. | | I agree it's an error. Back when we had one of those discussions it | seemed too resource-intensive to do both kinds of tests, and it's much | easier to do the "install everything" tests if you are always working | with a fixed library. | | Nowadays I think it's easier to run the tests on a VM that has exactly | the packages you specify, so people have less excuse not to do that on That is an old problem, and I argued about this (with you and others) for a decade or longer. And I often mentioned that e.g. _every_ Debian (or Ubuntu, I am sure the others distris do the same) build installs _excactly_ what is listed, and omitted packages _will_ cause an error. That was already easy to implement (on Unix system) several decades ago via chroot and related tricks; it is now trivial due to VMs or container use (which GH Actions approximates too, though it may start with 'too fat a container). So yes, it is technically easy, and we could pool the resources. But nobody is driving it so (as has been the case for years) nothing changes. Ever. | their own. I have a Github "workflow" here that does it for rgl: | | https://github.com/dmurdoch/rgl/actions/workflows/R-CMD-nosoft-check.yml | | BTW, I've just submitted another patch, this time for the usethis | package, which added "Suggests: testthat" and then used testthat | unconditionally. That won't help any other existing packages, but if it | is accepted it might help in the future. It has long been true that the main test runners (RUnit, testthat, now also tinytest) are automagically included, which is a defensible (if undocumented) special rule. Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] winUCRT failures
On 25 April 2021 at 11:46, Dirk Eddelbuettel wrote: | So yes, it is technically easy, and we could pool the resources. But nobody | is driving it so (as has been the case for years) nothing changes. Ever. Sorry, "nothing changes" is too harsh. We have in the last year or two gotten a new test or two in R CMD check. But it is still true that what should be an error still leads to needless failure and added confusion (c.f. beginning of this thread). We could do better, but won't as long as it isn't enforced. Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] winUCRT failures
On 25/04/2021 12:46 p.m., Dirk Eddelbuettel wrote: On 25 April 2021 at 12:27, Duncan Murdoch wrote: | On 25/04/2021 11:35 a.m., Dirk Eddelbuettel wrote: | > I last wrote about that four years ago under the title "Suggests != Depends" | > http://dirk.eddelbuettel.com/blog/2017/03/22#suggests_is_not_depends | > | > Of course, nothing changed. | > | > So when helping a R Core member last weekend by checking his package against | > just over 1000 reverse dependencies, I again had to manually wade through | > dozens of false errors of packages failing tests when packages they did NOT | > declare a dependency on were used unconditionally. That is still a very clear | > error to me, but I no longer expect these windmills will ever stop turning. | | I agree it's an error. Back when we had one of those discussions it | seemed too resource-intensive to do both kinds of tests, and it's much | easier to do the "install everything" tests if you are always working | with a fixed library. | | Nowadays I think it's easier to run the tests on a VM that has exactly | the packages you specify, so people have less excuse not to do that on That is an old problem, and I argued about this (with you and others) for a decade or longer. And I often mentioned that e.g. _every_ Debian (or Ubuntu, I am sure the others distris do the same) build installs _excactly_ what is listed, and omitted packages _will_ cause an error. That was already easy to implement (on Unix system) several decades ago via chroot and related tricks; it is now trivial due to VMs or container use (which GH Actions approximates too, though it may start with 'too fat a container). So yes, it is technically easy, and we could pool the resources. But nobody is driving it so (as has been the case for years) nothing changes. Ever. | their own. I have a Github "workflow" here that does it for rgl: | | https://github.com/dmurdoch/rgl/actions/workflows/R-CMD-nosoft-check.yml | | BTW, I've just submitted another patch, this time for the usethis | package, which added "Suggests: testthat" and then used testthat | unconditionally. That won't help any other existing packages, but if it | is accepted it might help in the future. It has long been true that the main test runners (RUnit, testthat, now also tinytest) are automagically included, which is a defensible (if undocumented) special rule. It's a bad rule. It's causing thousands of packages to fail now, because testthat won't pass checks on the winUCRT system. It's making the pain of winUCRT last much longer than it should, because nobody knows what problems exist in their own package if they can't install it because of missing dependencies. For example, as I said in the first message in this thread, The current CRAN release of rgl fails on winUCRT because of missing dependencies: 'htmlwidgets', 'htmltools', 'knitr', 'jsonlite', 'shiny', 'magrittr', 'crosstalk', 'manipulateWidget'. Tracing `htmlwidgets` shows it also fails because of missing dependencies: 'htmltools', 'jsonlite', 'yaml' and 'htmltools' fails because of missing dependencies 'digest', 'base64enc', 'rlang' A lot of those failures are ultimately caused by magrittr failing, and as far as I can see the only thing causing it to fail was that it used testthat unconditionally even though its DESCRIPTION file promised it would never do that. Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] winUCRT failures
On 25/04/2021 12:56 p.m., Duncan Murdoch wrote: On 25/04/2021 12:46 p.m., Dirk Eddelbuettel wrote: ... It has long been true that the main test runners (RUnit, testthat, now also tinytest) are automagically included, which is a defensible (if undocumented) special rule. It's a bad rule. It's causing thousands of packages to fail now, because testthat won't pass checks on the winUCRT system. It's making the pain of winUCRT last much longer than it should, because nobody knows what problems exist in their own package if they can't install it because of missing dependencies. For example, as I said in the first message in this thread, The current CRAN release of rgl fails on winUCRT because of missing dependencies: 'htmlwidgets', 'htmltools', 'knitr', 'jsonlite', 'shiny', 'magrittr', 'crosstalk', 'manipulateWidget'. Tracing `htmlwidgets` shows it also fails because of missing dependencies: 'htmltools', 'jsonlite', 'yaml' and 'htmltools' fails because of missing dependencies 'digest', 'base64enc', 'rlang' A lot of those failures are ultimately caused by magrittr failing, and as far as I can see the only thing causing it to fail was that it used testthat unconditionally even though its DESCRIPTION file promised it would never do that. One additional thought: If the testing package (i.e. testthat in this case) had been available but other suggested packages were not, it would be worth running tests with just testthat present: that might be why you called the decision defensible. I'd agree with that. However, it's still true that the fact that testthat has to be present to make magrittr available is a pretty serious flaw in magrittr and/or the CRAN processes. Hopefully magrittr's authors are less stubborn than R Core/CRAN, and will make their package more resilient. Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] winUCRT failures
> One additional thought: > > If the testing package (i.e. testthat in this case) had been available > but other suggested packages were not, it would be worth running tests > with just testthat present: that might be why you called the decision > defensible. I'd agree with that. > > However, it's still true that the fact that testthat has to be present > to make magrittr available is a pretty serious flaw in magrittr and/or > the CRAN processes. Hopefully magrittr's authors are less stubborn than > R Core/CRAN, and will make their package more resilient. Isn't this a 0/0 problem? If there are zero failures from zero tests, do we really want to declare that the package is ok? I'm not interested in participating in another debate about whether or not one should assume that suggested packages are available when checking a package. Some time ago, we decided to install all suggested packages when running reverse dependency checks and it has caused us few problems (especially since linux binaries for all CRAN packages are now readily available). Either way, isn't it easier for the handful of experienced developers who perform many R CMD check runs to install all suggested packages, rather than trying to get thousands of individual package maintainers to change their behaviour? Hadley -- http://hadley.nz __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] winUCRT failures
Who is responsible for the winUCRT checks? Perhaps that person could provide us with a list of root causes behind the testthat failures, and we could look into resolving them. Hadley On Sun, Apr 25, 2021 at 7:50 AM Duncan Murdoch wrote: > > The current CRAN release of rgl fails on winUCRT because of missing > dependencies: > > 'htmlwidgets', 'htmltools', 'knitr', 'jsonlite', 'shiny', 'magrittr', > 'crosstalk', 'manipulateWidget'. > > Tracing `htmlwidgets` shows it also fails because of missing dependencies: > > 'htmltools', 'jsonlite', 'yaml' > > and 'htmltools' fails because of missing dependencies > > 'digest', 'base64enc', 'rlang' > > but 'digest' only gets a warning (congratulations, Dirk!), 'base64enc' > gets a NOTE (hurray Simon!). 'rlang' is failing a test because of a > missing suggested dependency on 'glue'. At that point I stopped searching. > > Does anyone have a list of packages that actually need fixes? I'd like > to help those maintainers with the necessary updates. > > Duncan Murdoch > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- http://hadley.nz __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Call internal R functions in C
Hello All,
I'm developing a package with C code. My question may be naive: I have
several internal R functions that need to be called by C, but I cannot get
it to work or find a solution. It can work if I export those internal
functions in namespace, but it fails if I just want to keep them as
internal functions without exporting them. I guess I need some flags to
indicate the "internal" R internal functions? Could you please share your
thoughts on how to fix this? Much appreciated in advance!
// set up call to R function "R_function"
SEXP func_R;
PROTECT(func_R=lang2(install("R_function"), func_data));
Thanks,
C
[[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] Call internal R functions in C
On 25/04/2021 7:23 p.m., Cai Li wrote:
Hello All,
I'm developing a package with C code. My question may be naive: I have
several internal R functions that need to be called by C, but I cannot get
it to work or find a solution. It can work if I export those internal
functions in namespace, but it fails if I just want to keep them as
internal functions without exporting them. I guess I need some flags to
indicate the "internal" R internal functions? Could you please share your
thoughts on how to fix this? Much appreciated in advance!
// set up call to R function "R_function"
SEXP func_R;
PROTECT(func_R=lang2(install("R_function"), func_data));
It all depends on the environment where you evaluate that expression,
just as it would if it was R code. You can't see internal package
functions from the global environment, you need to evaluate them in the
package namespace environment.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Call internal R functions in C
Thanks Duncan! I was advised not to export those functions in the namespace
and keep them as internals. In terms of this, could you advise what
specific changes should I make to the C code so that I can evaluate them in
a suitable environment? I tried something like
"PROTECT(func_R=lang2(install("Package:::R_function"), func_data))," but it
did not work. Sorry this may be too naive and thanks again.
Cai
On Sun, Apr 25, 2021 at 8:46 PM Duncan Murdoch
wrote:
> On 25/04/2021 7:23 p.m., Cai Li wrote:
> > Hello All,
> >
> > I'm developing a package with C code. My question may be naive: I have
> > several internal R functions that need to be called by C, but I cannot
> get
> > it to work or find a solution. It can work if I export those internal
> > functions in namespace, but it fails if I just want to keep them as
> > internal functions without exporting them. I guess I need some flags to
> > indicate the "internal" R internal functions? Could you please share your
> > thoughts on how to fix this? Much appreciated in advance!
> >
> > // set up call to R function "R_function"
> > SEXP func_R;
> > PROTECT(func_R=lang2(install("R_function"), func_data));
> >
>
> It all depends on the environment where you evaluate that expression,
> just as it would if it was R code. You can't see internal package
> functions from the global environment, you need to evaluate them in the
> package namespace environment.
>
> Duncan Murdoch
>
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
