[R-pkg-devel] 'rlang' win-builder error for package without rlang dependency
Hi, My recent CRAN package submission failed with a win-builder error during the tests and vignette building *of the previously submitted version* [1]: ``` Error in library.dynam(lib, package, package.lib) : DLL 'rlang' not found: maybe not installed for this architecture? ``` (The log also shows another testing error with the new version which I can make neither heads nor tails of, but that’s a separate issue.) My package does not directly depend on 'rlang' (though it is a transitive 'Suggests' (build time) dependency via 'testthat'). I’m at a loss how to fix this issue. The closest I could find was [2], where the error is caused by tests being run for a mismatching architecture. In my case, the error seems to be caused by 'testthat' not being able to load the rlang DLL for x64 (weirdly the tests run to completion for the [mismatching] i386 architecture). Given that I don’t control (a) which architecture is tested on win-builder, nor (b) how 'testthat' loads its dependencies, how can I fix this? … or was this error included in the win-builder output of the new submission as a simple FYI and can be safely ignored? [1] https://win-builder.r-project.org/incoming_pretest/box_1.0.3_20210912_125241/Debian/00check.log [2] https://github.com/r-hub/rhub/issues/476 -- Konrad Rudolph // @klmr [[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] 'rlang' win-builder error for package without rlang dependency
Hi Carrie, Thanks for the prompt reply, good to hear that I’m not the only one experiencing this (the fact that this hadn’t been posted to r-package-devel yet had dispirited me). I’ll try resubmitting as soon as I’ve taken care of the other (real) issues. On Sun, Sep 12, 2021 at 6:31 PM Carrie Tribble wrote: > Hi Konrad, > > This happened to me too on Thursday. I tried retesting on Friday and ran > into the same problem with a different function (vctrs instead of rlang). > But Friday night when I retested, the problem had resolved itself. Curious > to hear what could have happened, but I'd also suggest retesting now if if > you haven't tried again since. > > Cheers, > Carrie > > On Sun, Sep 12, 2021, 7:26 AM Konrad Rudolph > wrote: > >> Hi, >> >> My recent CRAN package submission failed with a win-builder error during >> the tests and vignette building *of the previously submitted version* [1]: >> >> ``` >> Error in library.dynam(lib, package, package.lib) : >> DLL 'rlang' not found: maybe not installed for this architecture? >> ``` >> >> (The log also shows another testing error with the new version which I can >> make neither heads nor tails of, but that’s a separate issue.) >> >> My package does not directly depend on 'rlang' (though it is a transitive >> 'Suggests' (build time) dependency via 'testthat'). I’m at a loss how to >> fix this issue. The closest I could find was [2], where the error is >> caused >> by tests being run for a mismatching architecture. In my case, the error >> seems to be caused by 'testthat' not being able to load the rlang DLL for >> x64 (weirdly the tests run to completion for the [mismatching] i386 >> architecture). Given that I don’t control (a) which architecture is tested >> on win-builder, nor (b) how 'testthat' loads its dependencies, how can I >> fix this? >> >> … or was this error included in the win-builder output of the new >> submission as a simple FYI and can be safely ignored? >> >> [1] >> >> https://win-builder.r-project.org/incoming_pretest/box_1.0.3_20210912_125241/Debian/00check.log >> [2] https://github.com/r-hub/rhub/issues/476 >> >> -- >> Konrad Rudolph // @klmr >> >> [[alternative HTML version deleted]] >> >> __ >> R-package-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-package-devel >> > -- Konrad Rudolph // @klmr [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] How to format the NEWS.md file for CRAN submissions?
My package is creating a CRAN check NOTE because CRAN does not like the way my NEWS.md file [1] is formatted. I am largely adhering to existing conventions with regards to my NEWS.md, in particular the (rather minimal) GNU conventions [2] mentioned in R-exts as well as the conventions used by ‘pkgdown’ to compile the file into a web page. The one peculiarity of my NEWS.md file (and where it diverges from the documented ‘pkgdown’ convention) is caused by the fact that my package has undergone a name change in the past. As a consequence, not all headings in the NEWS.md file follow the format `# ‹pkgname› ‹version›`. Consequently, the CRAN check complains > Cannot extract version info from the following section titles: > modules 0.x I have two questions: 1. Am I overlooking where the CRAN requirements for NEWS files are documented? As far as I can see I am not violating a documented rule. 2. What is the best way of avoiding this NOTE _without_ dropping the changelog pre package name change? In particular, since ‘pkgdown’ does not support this I would like keep these changes in a single NEWS.md file rather than moving them into a separate file. Likewise, I think it would be misleading (and hence undesirable) to change the section headings to use the current package name for the old revisions. [1] https://github.com/klmr/box/blob/9f35bd28b26306fe94ade874c2b93a89ae3f3a61/NEWS.md [2] https://www.gnu.org/prep/standards/standards.html#NEWS-File Cheers, Konrad -- Konrad Rudolph // @klmr [[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] How to format the NEWS.md file for CRAN submissions?
Hi Duncan, Thanks, that‘s perfect. So the issue in my case was the ‘0.0.x’ version instead of the package name. That’s easily fixable, as verified by running `utils::news()` on my package. Cheers, Konrad On Mon, Apr 24, 2023 at 10:54 PM Duncan Murdoch wrote: > On 24/04/2023 4:39 p.m., Konrad Rudolph wrote: > > My package is creating a CRAN check NOTE because CRAN does not like the > way > > my NEWS.md file [1] is formatted. > > > > I am largely adhering to existing conventions with regards to my NEWS.md, > > in particular the (rather minimal) GNU conventions [2] mentioned in > R-exts > > as well as the conventions used by ‘pkgdown’ to compile the file into a > web > > page. The one peculiarity of my NEWS.md file (and where it diverges from > > the documented ‘pkgdown’ convention) is caused by the fact that my > package > > has undergone a name change in the past. As a consequence, not all > headings > > in the NEWS.md file follow the format `# ‹pkgname› ‹version›`. > > Consequently, the CRAN check complains > > > >>Cannot extract version info from the following section titles: > >> modules 0.x > > > > I have two questions: > > > > 1. Am I overlooking where the CRAN requirements for NEWS files are > > documented? As far as I can see I am not violating a documented rule. > > The documentation is in the ?util::news help topic. It says: > > "File ‘NEWS.md’ should contain the news in Markdown (following the > CommonMark (https://commonmark.org/) specification), with the primary > heading level giving the version number after a prefix followed by a > space, and optionally followed by a space and a parenthesized ISO 8601 > format date." > > > > 2. What is the best way of avoiding this NOTE _without_ dropping the > > changelog pre package name change? In particular, since ‘pkgdown’ does > not > > support this I would like keep these changes in a single NEWS.md file > > rather than moving them into a separate file. Likewise, I think it would > be > > misleading (and hence undesirable) to change the section headings to use > > the current package name for the old revisions. > > I don't think it cares what the prefix is, so you could use something > other than the current package name there. > > Duncan Murdoch > > > > > > [1] > > > https://github.com/klmr/box/blob/9f35bd28b26306fe94ade874c2b93a89ae3f3a61/NEWS.md > > [2] https://www.gnu.org/prep/standards/standards.html#NEWS-File > > > > Cheers, > > Konrad > > > > -- Konrad Rudolph // @klmr [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] May .External2() be used in packages?
Hello, Is the `.External2()` function part of the public API, and can it be used in R packages submitted to CRAN? I would like to start using it in a package, and there *are* packages on CRAN which use it. But its man page [1] calls it “internal”, R-exts doesn’t mention it at all (unlike `.C()`, `.Call()` and `.External()`), and it doesn’t have any actual documentation. In the context of the recent tightening of the C API CRAN rules, this makes me concerned that `.External2()` might be next on the chopping block. [1] https://stat.ethz.ch/R-manual/R-devel/library/base/html/Foreign-internal.html Cheers, -- Konrad Rudolph // @klmr [[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] [External] May .External2() be used in packages?
Thanks, That’s a shame but good to know. Packages that for whatever reason have chosen to use it > could instead use .External(), and that is what yo should use. Unfortunately .External() is not a replacement (in general, or for my purpose) since it’s missing the `call` and `rho` arguments, and computing the same information without these arguments in C code is far from trivial. -- Konrad Rudolph // @klmr [[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] [External] May .External2() be used in packages?
Hi Luke,
Thanks, obviously that will work and I didn’t think of it.
In my defence I had previously used match.call() to capture the call on the
R side, and representative microbenchmarks show that it adds a prohibitive
overhead for my use-case. On the C side I only need the caller information
in the non-performance sensitive path (for error message formatting) so I
can compute it on demand. And I hadn’t included .External2() in that
benchmark yet. I assume that it’ll be no faster than the way you proposed,
so it isn’t actually needed in my case — just as you said.
On Wed, 1 May 2024 at 21:32, wrote:
> yOn Wed, 1 May 2024, Konrad Rudolph wrote:
>
> > Thanks,
> >
> > That’s a shame but good to know.
> >
> > Packages that for whatever reason have chosen to use it
> > could instead use .External(), and that is what yo should use.
> >
> >
> > Unfortunately .External() is not a replacement (in general, or for my
> > purpose) since it’s missing the `call` and `rho` arguments, and computing
> > the same information without these arguments in C code is far from
> trivial.
>
> The call you would get is not likely to be all that useful, but it is
> the one you wrote. The environment is the one you get from environment()
> at the point where you would call .External2. So instead of
>
> .External2("foo", x, y)
>
> do
>
> .External("foo", quote(.External2("foo", x, y)), environment(), x, y)
>
> and adjust your C function accordingly.
>
> Best,
>
> luke
>
> > --
> > Konrad Rudolph // @klmr
> >
> >
>
> --
> Luke Tierney
> Ralph E. Wareham Professor of Mathematical Sciences
> University of Iowa Phone: 319-335-3386
> Department of Statistics andFax: 319-335-3017
> Actuarial Science
> 241 Schaeffer Hall email: luke-tier...@uiowa.edu
> Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
--
Konrad Rudolph // @klmr
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] R CMD check failure during vignette rebuilding
I have a package vignette that reproducibly fails the second time
round in `R CMD check`, in the “checking re-building of vignette
outputs” step.
I have uploaded a small reprex to GitHub [1]. But in a nutshell the
vignette contains a subfolder `foo`, and a file `foo/bar`. And the
`test.rmd` vignette contains the following R code:
> newfile = file.path(getwd(), 'foo', 'baz')
> writeLines('baz', newfile)
This code causes `R CMD check` to delete the folder `foo` inside
`00_pkg_src/vignettes` after building the vignette, leading to the
following error message further down the line:
> Error(s) in re-building vignettes:
> ...
> --- re-building ‘test.rmd’ using rmarkdown
> Quitting from lines 8-10 (test.rmd)
> Error: processing vignette 'test.rmd' failed with diagnostics:
> cannot open the connection
> --- failed re-building ‘test.rmd’
This seems to be due to the cleanup after building vignettes inside
`tools::buildVignette`, because creating a file inside a folder
changes the directory subfolder modification time (on POSIX-like
systems) so the whole folder is deleted in cleanup, rather than just
the file. Can I prevent this?
[1] https://github.com/klmr/vignettetest
--
Konrad Rudolph // @klmr
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R CMD check failure during vignette rebuilding
Hi Duncan,
Thanks for the explanation. Using a temporary directory is what I’m
doing at the moment as a workaround.
What confused me was that `R CMD check` *already* works inside a new
directory (a set of different ones, in fact), and it doesn’t seem to
be documented anywhere that this is the intended behaviour (the
documentation of `buildVignettes` only mentions it removes “newly
created … files”, not existing folders), so I thought creating
temporary files under `vignettes` was fair game. Could you clarify
whether this behaviour (deleting existing folders during cleanup) is
intentional? If so, could it be documented more explicitly?“
On Tue, Apr 14, 2020 at 1:53 PM Duncan Murdoch wrote:
>
> On 14/04/2020 6:23 a.m., Konrad Rudolph wrote:
> > I have a package vignette that reproducibly fails the second time
> > round in `R CMD check`, in the “checking re-building of vignette
> > outputs” step.
> >
> > I have uploaded a small reprex to GitHub [1]. But in a nutshell the
> > vignette contains a subfolder `foo`, and a file `foo/bar`. And the
> > `test.rmd` vignette contains the following R code:
> >
> >> newfile = file.path(getwd(), 'foo', 'baz')
> >> writeLines('baz', newfile)
> >
> > This code causes `R CMD check` to delete the folder `foo` inside
> > `00_pkg_src/vignettes` after building the vignette, leading to the
> > following error message further down the line:
> >
> >>Error(s) in re-building vignettes:
> >> ...
> >>--- re-building ‘test.rmd’ using rmarkdown
> >>Quitting from lines 8-10 (test.rmd)
> >>Error: processing vignette 'test.rmd' failed with diagnostics:
> >>cannot open the connection
> >>--- failed re-building ‘test.rmd’
> >
> > This seems to be due to the cleanup after building vignettes inside
> > `tools::buildVignette`, because creating a file inside a folder
> > changes the directory subfolder modification time (on POSIX-like
> > systems) so the whole folder is deleted in cleanup, rather than just
> > the file. Can I prevent this?
> >
> > [1] https://github.com/klmr/vignettetest
> >
>
> Normally the checks don't want you to be writing files outside of the
> temp dir, because if a user processed your vignette, it might stomp on
> their files. So can't you change that code to
>
>dir.create(tempdir(), 'foo')
>newfile <- file.path(tempdir(), 'foo', 'baz')
>
> Duncan Murdoch
--
Konrad Rudolph // @klmr
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] How to avoid R CMD check warning for documentation of non-package functions?
My package provides infrastructure support for callback functions
defined in special environments in user code. They are conceptually
similar (in fact, almost identical) to the `.onLoad` etc. “hooks for
namespace events” in base R [1]. Now I’m adding documentation for
these functions, via the following Rd code (or the equivalent roxygen2
code annotating a `NULL` value):
```
\name{topicname}
\alias{topicname}
\alias{onload}
\title{Hooks for environment events}
\usage{
onload(env)
}
\arguments{
\item{env}{the environment}
}
\description{
Short description
}
```
Unfortunately, this causes an `R CMD check` warning:
> Functions or methods with usage in documentation object 'topicname' but not
> in code:
> ‘onload’
Right: this function does not exist in my package, and it *should not*
exist in the package. Yet I do need to document it for users. What is
the recommended way for doing so? In fact, from my reading of the R
source, the base R documentation of ‘ns-hooks’ doesn’t seem to do
anything special, and would presumably also cause this warning.
I’m open to doing this differently, but I’d strongly prefer if these
functions had their own help topic, with their own “usage” section. I
don’t just want to add them as a custom section to the package
documentation topic if this is at all avoidable.
[1]: https://stat.ethz.ch/R-manual/R-devel/library/base/html/ns-hooks.html
PS: A note on API design, I considered doing this differently: rather
than define hooks via “special names”, users would define them by
passing callbacks to a call to a package function; e.g.
`mypkg::define_onload(function (env) { … })`. This would be
conceptually similar to R’s `setHook` [2]. However, from the user’s
point of view there’s no advantage to doing it this way, and it’s more
verbose. Defining callbacks via special names has ample precedence,
both in R and in other languages. And I don’t think `R CMD check`
warnings should dictate API design in this manner.
[2] https://stat.ethz.ch/R-manual/R-devel/library/base/html/userhooks.html
--
Konrad Rudolph // @klmr
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] How to avoid R CMD check warning for documentation of non-package functions?
On Wed, Dec 2, 2020 at 7:44 PM Duncan Murdoch wrote:
> I haven't tried this, but I believe if you define functions with the
> right name and header in your package but don't export them the warning
> will go away.
Thanks, works like a charm.
> If that doesn't work (or defining those causes other issues), a more
> involved workaround would be to change the \docType{} declaration for
> the help page. \docType{package} is the most free-form, but you might
> get warned if you have two of them. \docType{data} might be flexible
> enough. If you do this, you won't use \usage{} or \arguments{}, you'll
> put together your own sections using \section{Usage}{ ... } and
> \section{Arguments}{ ... } and try to get the formatting right.
I’ll keep this in mind! It might come handy.
--
Konrad Rudolph // @klmr
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
