[R-pkg-devel] check error with r-devel-windows-ix86+x86_64 due to missing Hmisc package

[Gilbert Ritschard]

Hi all,

The submission of an update of TraMineRextras on the CRAN does not pass the 
test due to an error with r-devel-windows-ix86+x86_64.

The error says:

> library('TraMineRextras')
  Loading required package: TraMineR
  Error: package or namespace load failed for 'TraMineR' in 
find.package(package, lib.loc, verbose = verbose):
   there is no package called 'Hmisc'

How can I fix this this error? The package relies strongly on TraMineR, I 
cannot remove the dependence on that package.

The Check Results table for Hmisc shows an error for r-devel-x86_64-gcc10-UCRT 
due to missing package plotly.

Best.
Gilbert


[[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] check error with r-devel-windows-ix86+x86_64 due to missing Hmisc package

[Duncan Murdoch]

On 23/06/2021 7:41 a.m., Gilbert Ritschard wrote:

Hi all,

The submission of an update of TraMineRextras on the CRAN does not pass the 
test due to an error with r-devel-windows-ix86+x86_64.

The error says:


library('TraMineRextras')

   Loading required package: TraMineR
   Error: package or namespace load failed for 'TraMineR' in 
find.package(package, lib.loc, verbose = verbose):
there is no package called 'Hmisc'

How can I fix this this error? The package relies strongly on TraMineR, I 
cannot remove the dependence on that package.

The Check Results table for Hmisc shows an error for r-devel-x86_64-gcc10-UCRT 
due to missing package plotly.


That's a real error in Hmisc, but it should be easy to fix.  Hmisc 
suggests plotly, then uses it unconditionally.  You could prepare and 
test a patch for Hmisc to fix this issue (reducing the ERROR to a NOTE 
if that's the only issue), and then your package wouldn't get this error.


I'd do so myself, but I have very expensive Internet access most of the 
time for the next few weeks.


Duncan Murdoch

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

Re: [R-pkg-devel] check error with r-devel-windows-ix86+x86_64 due to missing Hmisc package

[Gilbert Ritschard]

Thanks for this suggestion.

Pushing the investigation a bit further, I found that the error resulted in 
chain (curl -> httr -> plotly -> Hmisc -> TraMineR -> TraMineRextras) from an 
issue of the package curl with the ucrt tool. An update of curl with a fix has 
been released today. So seems that I just have to wait until curl is built for 
the ucrt experimental toolchain.

Gilbert
  

> -Original Message-
> From: Duncan Murdoch 
> Sent: mercredi 23 juin 2021 14:19
> To: Gilbert Ritschard ; R-package-devel@r-
> project.org
> Subject: Re: [R-pkg-devel] check error with r-devel-windows-ix86+x86_64 due to
> missing Hmisc package
> 
> On 23/06/2021 7:41 a.m., Gilbert Ritschard wrote:
> > Hi all,
> >
> > The submission of an update of TraMineRextras on the CRAN does not pass the
> test due to an error with r-devel-windows-ix86+x86_64.
> >
> > The error says:
> >
> >> library('TraMineRextras')
> >Loading required package: TraMineR
> >Error: package or namespace load failed for 'TraMineR' in
> find.package(package, lib.loc, verbose = verbose):
> > there is no package called 'Hmisc'
> >
> > How can I fix this this error? The package relies strongly on TraMineR, I 
> > cannot
> remove the dependence on that package.
> >
> > The Check Results table for Hmisc shows an error for r-devel-x86_64-gcc10-
> UCRT due to missing package plotly.
> 
> That's a real error in Hmisc, but it should be easy to fix.  Hmisc suggests 
> plotly,
> then uses it unconditionally.  You could prepare and test a patch for Hmisc 
> to fix
> this issue (reducing the ERROR to a NOTE if that's the only issue), and then 
> your
> package wouldn't get this error.
> 
> I'd do so myself, but I have very expensive Internet access most of the time 
> for the
> next few weeks.
> 
> Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] find functions with missing Rd tags

[Alex Chubaty]

During a recent package submission process, a CRAN maintainer showed one of
their checks found missing \value{} documentation in some package Rd files,
and asked us to ensure all exported functions have their return values
described.

This check (for missing Rd values) is not run by the default checks, so I
have no idea how to quickly identify which functions are missing those
components, without manually inspecting everything. I am hoping that
someone here can tell me which special R CMD check incantation, or similar
I can use to find _exported_ functions with missing Rd tags.

Thank you,
Alex

[[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] find functions with missing Rd tags

[Henrik Bengtsson]

$ grep -L -F "\value{" man/*.Rd

/Henrik

On Wed, Jun 23, 2021 at 10:58 AM Alex Chubaty  wrote:
>
> During a recent package submission process, a CRAN maintainer showed one of
> their checks found missing \value{} documentation in some package Rd files,
> and asked us to ensure all exported functions have their return values
> described.
>
> This check (for missing Rd values) is not run by the default checks, so I
> have no idea how to quickly identify which functions are missing those
> components, without manually inspecting everything. I am hoping that
> someone here can tell me which special R CMD check incantation, or similar
> I can use to find _exported_ functions with missing Rd tags.
>
> Thank you,
> Alex
>
> [[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

Re: [R-pkg-devel] find functions with missing Rd tags

[Martin Morgan]

I looked at the help page for ?tools::Rd_db and came up with this script; maybe 
not perfect...

Create a database of Rd information for the package of interest

library(tools)
pkg_of_interest <- "stats"
db <- Rd_db(pkg_of_interest)

Extract relevant fields / summary of fields into a database. This is from the 
example code on the ?Rd_db page. There can only be one `name` or `value` tag, 
but several `alias` tags

name <- lapply(db, tools:::.Rd_get_metadata, "name")
alias <- lapply(db, tools:::.Rd_get_metadata, "alias")
value <- lapply(db, tools:::.Rd_get_metadata, "value")

n_aliases <- lengths(alias)
df <- data.frame(
file_name = rep(names(db), n_aliases),
name = rep(unlist(name, use.names = FALSE), n_aliases),
alias = unlist(alias, use.names = FALSE),
has_value = rep(lengths(value) > 0, n_aliases)
)

Create subsets of the database, and find the aliases that have no values. This 
is trying to allow for the possibility that an alias occurs in more than one 
help file (is this allowed?)

alias_with_value <- subset(df, has_value)
alias_without_value <- subset(df, !has_value)
no_value <- subset(alias_without_value, !alias %in% alias_with_value$alias)

Find all the exports in the package, and subset the help pages to just those.

exports <- getNamespaceExports(pkg_of_interest)
subset(no_value, alias %in% exports)

This still requires some manual review; here are some entries with comments

file_name   name   alias has_value
84  biplot.Rd biplot  biplot FALSE

yep, ?biplot finds a help page that documents biplot() and does not have a 
value section. It does have a 'Side effect' section, but I think that's 
non-standard

268  glm.summaries.Rd  glm.summaries   residuals.glm FALSE

This is a method for the generic residuals() applied to an object of class glm; 
it should still have a value section, I think...

627  stats-defunct.Rd  stats-defunct arima0.diag FALSE

I guess it  makes sense for defunct functions not to be fully documented, 
though maybe it would be helpful for those trying to migrate their code...

Martin Morgan


On 6/23/21, 1:58 PM, "R-package-devel on behalf of Alex Chubaty" 
 
wrote:

During a recent package submission process, a CRAN maintainer showed one of
their checks found missing \value{} documentation in some package Rd files,
and asked us to ensure all exported functions have their return values
described.

This check (for missing Rd values) is not run by the default checks, so I
have no idea how to quickly identify which functions are missing those
components, without manually inspecting everything. I am hoping that
someone here can tell me which special R CMD check incantation, or similar
I can use to find _exported_ functions with missing Rd tags.

Thank you,
Alex

[[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

Re: [R-pkg-devel] Best way to build CRAN packages that include Rust source?

[David Norris]

To follow up, I’m quite settled on (2) now, as I’ve been able to adapt the 
Makevars files of package ‘gifski’ to achieve a successful R-CMD-check across 
multiple GitHub virtual platforms including windows.
For anyone interested, the Makevars & Makevars.win files are in 
https://github.com/dcnorris/precautionary/tree/main/src
The GitHub workflow is at 
https://github.com/dcnorris/precautionary/blob/main/.github/workflows/R-CMD-check.yaml
Kind regards,
David

From: R-package-devel  on behalf of 
David Norris 
Date: Monday, May 3, 2021 at 2:44 PM
To: "r-package-devel@r-project.org" 
Subject: [R-pkg-devel] Best way to build CRAN packages that include Rust source?

I am appreciating 2 distinct approaches currently used to compile Rust code in 
R packages:

1. LinkingTo: cargo, as done in https://CRAN.R-project.org/package=salso

2. A more ‘traditional’-looking approach built on Autoconf & Automake 
https://CRAN.R-project.org/package=gifski

Is there any reason why one or the other would be preferred for a CRAN 
submission?
Would one or the other design better facilitate Rust’s eventual elevation to 
‘first-class’ status (like C++, Fortran) for compiling code in R packages?

In favor of (1), it seems to me that the “Reverse linking to:” entry at 
https://CRAN.R-project.org/package=cargo nicely advertises packages that use 
Rust, which could be useful for example code, etc.
In favor of (2), it seems completely idiomatic—and so potentially more 
conducive to achieving first-class status for Rust.


[[alternative HTML version deleted]]

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


[[alternative HTML version deleted]]

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