Re: [R-pkg-devel] Order of repo access from options("repos")

[Martin Morgan]

available.packages indicates that

 By default, the return value includes only packages whose version
 and OS requirements are met by the running version of R, and only
 gives information on the latest versions of packages.

So all repositories are consulted and then the result filtered to contain just 
the most recent version of each. Does it matter then what order the 
repositories are visited?

Martin Morgan

From: R-package-devel  on behalf of Greg 
Hunt 
Date: Sunday, March 31, 2024 at 7:35 AM
To: Dirk Eddelbuettel 
Cc: List r-package-devel 
Subject: Re: [R-pkg-devel] Order of repo access from options("repos")
Dirk,
Sadly I can't use localhost for all of those.  172.17.0.1 is an internal
Docker IP, not the localhost address (127.0.0.1), they are there to handle
two different scenarios and different ones will fail to resolve in
different scenarios.  Are you saying that the DNS lookup adds a timing
issue to the search order?  Isn't the list deterministically ordered?


Greg

On Sun, 31 Mar 2024 at 22:15, Dirk Eddelbuettel  wrote:

>
> Greg,
>
> There are AFAICT two issues here: how R unrolls the named vector that is
> the
> 'repos' element in the list 'options', and how your computer resolves DNS
> for
> localhost vs 172.17.0.1.  I would try something like
>
>options(repos = c(CRAN = "http://localhost:3001/proxy;,
>  C = "http://localhost:3002;,
>  B = "http://localhost:3003/proxy;,
>  A = "http://localhost:3004;))
>
> or the equivalent with 172.17.0.1. When I do that here I get errors from
> first to last as we expect:
>
>> options(repos = c(CRAN = "http://localhost:3001/proxy;,
>  C = "http://localhost:3002;,
>  B = "http://localhost:3003/proxy;,
>  A = "http://localhost:3004;))
>> available.packages()
>Warning: unable to access index for repository
> http://localhost:3001/proxy/src/contrib:
>  cannot open URL 'http://localhost:3001/proxy/src/contrib/PACKAGES'
>Warning: unable to access index for repository
> http://localhost:3002/src/contrib:
>  cannot open URL 'http://localhost:3002/src/contrib/PACKAGES'
>Warning: unable to access index for repository
> http://localhost:3003/proxy/src/contrib:
>  cannot open URL 'http://localhost:3003/proxy/src/contrib/PACKAGES'
>Warning: unable to access index for repository
> http://localhost:3004/src/contrib:
>  cannot open URL 'http://localhost:3004/src/contrib/PACKAGES'
> Package Version Priority Depends Imports LinkingTo Suggests
> Enhances License License_is_FOSS License_restricts_use OS_type Archs MD5sum
> NeedsCompilation File Repository
>>
>
> Dirk
>
> --
> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>

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

Re: [R-pkg-devel] Bioconductor reverse dependency checks for a CRAN package

[Martin Morgan]

BiocManager (the recommended way to install Bioconductor packages) at the end 
of the day does essentially install.packages(repos = 
BiocManager::repositories()), ensuring that the right versions of Bioconductor 
packages are installed for the version of R in use. Maybe this is moot though 
if the goal is to emulate CRAN, since I believe they use 
utils:::.BioC_version_associated_with_R_version().

There is a Bioconductor docker container, extending rocker 
https://github.com/Bioconductor/bioconductor_docker ; I don't know whether this 
would be more or less work than alternatives. And an exploratory 
https://github.com/Bioconductor/bioc2u; I don't know the status of that project.

At some point the scale tips from installing packages from standard 
repositories to using a local clone 
https://bioconductor.org/about/mirrors/mirror-how-to/.

Martin Morgan

From: R-package-devel  on behalf of Ivan 
Krylov via R-package-devel 
Date: Tuesday, January 30, 2024 at 10:57 AM
To: r-package-devel@r-project.org 
Subject: [R-pkg-devel] Bioconductor reverse dependency checks for a CRAN package
Hello R-package-devel,

What would you recommend in order to run reverse dependency checks for
a package with 182 direct strong dependencies from CRAN and 66 from
Bioconductor (plus 3 more from annotations and experiments)?

Without extra environment variables, R CMD check requires the Suggested
packages to be available, which means installing...

revdepdep <- package_dependencies(revdep, which = 'most')
revdeprest <- package_dependencies(
 unique(unlist(revdepdep)),
 which = 'strong', recursive = TRUE
)
length(setdiff(
 unlist(c(revdepdep, revdeprest)),
 unlist(standard_package_names())
))

...up to 1316 packages. 7 of these suggested packages aren't on CRAN or
Bioconductor (because they've been archived or have always lived on
GitHub), but even if I filter those out, it's not easy. Some of the
Bioconductor dependencies are large; I now have multiple gigabytes of
genome fragments and mass spectra, but also a 500-megabyte arrow.so in
my library. As long as a data package declares a dependency on your
package, it still has to be installed and checked, right?

Manually installing the SystemRequirements is no fun at all, so I've
tried the rocker/r2u container. It got me most of the way there, but
there were a few remaining packages with newer versions on CRAN. For
these, I had to install the system packages manually in order to build
them from source.

Someone told me to try the rocker/r-base container together with pak.
It was more proactive at telling me about dependency conflicts and
would have got me most of the way there too, except it somehow got me a
'stringi' binary without the corresponding libicu*.so*, which stopped
the installation process. Again, nothing that a bit of manual work
wouldn't fix, but I don't feel comfortable setting this up on a CI
system. (Not on every commit, of course - that would be extremely
wasteful - but it would be nice if it was possible to run these checks
before release on a different computer and spot more problems this way.)

I can't help but notice that neither install.packages() nor pak() is
the recommended way to install Bioconductor packages. Could that
introduce additional problems with checking the reverse dependencies?

Then there's the check_packages_in_dir() function itself. Its behaviour
about the reverse dependencies is not very helpful: they are removed
altogether or at least moved away. Something may be wrong with my CRAN
mirror, because some of the downloaded reverse dependencies come out
with a size of zero and subsequently fail the check very quickly.

I am thinking of keeping a separate persistent library with all the
1316 dependencies required to check the reverse dependencies and a
persistent directory with the reverse dependencies themselves. Instead
of using the reverse=... argument, I'm thinking of using the following
scheme:

1. Use package_dependencies() to determine the list of packages to test.
2. Use download.packages() to download the latest version of everything
if it doesn't already exist. Retry if got zero-sized or otherwise
damaged tarballs. Remove old versions of packages if a newer version
exists.
3. Run check_packages_in_dir() on the whole directory with the
downloaded reverse dependencies.

For this to work, I need a way to run step (3) twice, ensuring that one
of the runs is performed with the CRAN version of the package in the
library and the other one is performed with the to-be-released version
of the package in the library. Has anyone already come up with an
automated way to do that?

No wonder nobody wants to maintain the XML package.

--
Best regards,
Ivan

__
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

Re: [R-pkg-devel] I'm trying to include phyloseq as a CRAN package dependency and for the life of me I can't figure it out

[Martin Morgan]

CRAN knows about Bioconductor packages, so add phyloseq to Depends: , Imports:, 
or Suggests: as appropriate.

These CRAN packages seem to Import phyloseq, for instance

> db = available.packages(repos = "https://cloud.R-project.org;)
> rownames(db)[grepl("phyloseq", db[,"Imports"])]
[1] "adaptiveGPCA"  "breakaway" "chem16S"
[4] "HTSSIP""HybridMicrobiomes" "microbial"
[7] "MicrobiomeStat""mixKernel" "SigTree"
[10] "SIPmg" "treeDA"


From: R-package-devel  on behalf of 
Sharon Bewick 
Date: Monday, December 4, 2023 at 6:17 AM
To: r-package-devel@r-project.org 
Subject: [R-pkg-devel] I'm trying to include phyloseq as a CRAN package 
dependency and for the life of me I can't figure it out
I had this package included in a previous upload and it didn’t cause errors. 
However, now it is getting flagged as an error. I’ve included biocViews: 
phyloseq in the DESCRIPTION file, but that did not help. Unfortunately, I 
cannot make phyloseq a weak dependency. It can be installed through 
Bioconductor but not CRAN. Any advice, or examples would be appreciated. I have 
tried most of the ‘solutions’ I have found online without success.

Thanks!
Sharon

[[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 declare Bioconductor Dependencies in the Description File of my R Package

[Martin Morgan]

CRAN is fine with Bioconductor Depends: and Imports: dependencies, as 
previously mentioned. This is because the CRAN maintainers explicitly configure 
their system to know about Bioconductor package repositories.

Users face a different challenge -- many users will not have identified (e.g., 
via `setRepositories()` a Bioconductor repository, so when they try to install 
your package it will fail in a way that you have no control over -- a generic 
message saying that the Bioconductor dependencies was not found.

You could mitigate this by advertising that your CRAN package should be 
installed via `BiocManager::install("")`, which defines 
appropriate repositories for both CRAN and Bioconductor, but there is no way to 
unambiguously communicate this to users.

Martin

From: R-package-devel  on behalf of 
Ruff, Sergej 
Date: Wednesday, May 3, 2023 at 11:13 AM
To: Dirk Eddelbuettel 
Cc: r-package-devel@r-project.org 
Subject: Re: [R-pkg-devel] How to declare Bioconductor Dependencies in the 
Description File of my R Package
Thank you, Dirk.


I see your dependencies are Suggested. I know that Suggested dependencies 
should be conditional.


Do you know if Non-Cran (Bioconductor) packages need to be conditional?  Do you 
have any experiece regarding Non-CRAN Dependencies

and how to handle them?


I believe Duncan Murdoch's experience and opinion regarding that topic, but i 
take any second and third opinion to be sure.


Thank you for your help.


Sergej


Von: Dirk Eddelbuettel 
Gesendet: Mittwoch, 3. Mai 2023 16:22:09
An: Ruff, Sergej
Cc: Duncan Murdoch; Ivan Krylov; r-package-devel@r-project.org
Betreff: Re: [R-pkg-devel] How to declare Bioconductor Dependencies in the 
Description File of my R Package


Sergej,

Please consider:

  - there are nearly 20k CRAN packages

  - all of them are mirrored at https://github.com/cran so you can browse

  - pick any one 'heavy' package you like, Seurat is a good example; there
are other examples in geospatial or bioinformatics etc

  - you can browse _and search_ these to your hearts content

Here is an example of mine. In RcppArmadillo, years ago we (thanks to fine
Google Summer of Code work by Binxiang Ni) added extended support for sparse
matrices pass-through / conversione from R to C++ / Armadillo and back. That
is clearly an optional feature as most uses of (Rcpp)Armadillo use dense
matrices. So all code and test code is _conditional_.  File DESCRIPTION has

   Suggests: [...], Matrix (>= 1.3.0), [...], reticulate, slam

mostly for tests. I.e. We have very little R code: in one single file
R/SciPy2R.R we switched to doing this via reticulate and opee the function
with

if (!requireNamespace("reticulate", quietly=TRUE)) {
stop("You must install the 'reticulate' package (and have SciPy).", 
call.=FALSE)
}

after an actual deprecation warning (as there was scipy converter once).

Similarly, the testsuites in inst/tinytests/* have several

if (!requireNamespace("Matrix", quietly=TRUE)) exit_file("No Matrix 
package")

as well as

if (!requireNamespace("reticulate", quietly=TRUE)) exit_file("Package 
reticulate missing")

if (!packageVersion("reticulate") >= package_version("1.14"))
exit_file("SciPy not needed on newer reticulate")

and tests for slam (another sparse matrix package besides the functionality
in Matrix).

Hopefully this brief snapshot gives you an idea.  There are (likely!!)
thousandss of examples you can browse, and I am sure you will find something.
If you have further (concrete) questions please do not hesitate to use the
resource of this list.

Cheers (or I should say "mit Braunschweiger Gruessen nach Hannover),

Dirk

--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-pkg-devel] How to declare Bioconductor Dependencies in the Description File of my R Package

[Martin Morgan]

I would not follow the instructions in RTIGER�s README for installing 
Bioconductor packages.

BiocManager::install(�RTIGER�) would install both CRAN and Bioconductor 
dependencies of RTIGER, and would be my preferred instruction in a README or 
INSTALL file. A complete instruction might be to install your package as if it 
were on Bioconductor �

If (!requireNamepace(�BiocManager�, quietly = TRUE))
install.packages(�BiocManager�)
BiocManager::install(��)

It does not make sense to me to have instructions in .onAttach / .onLoad or in 
each function for the user to install a �Suggests:� package, when actually the 
package is required for use and belongs in Imports: or perhaps Depends:.

The instruction to use �version = �3.14�� of Bioconductor in the RTIGER 
document is not universally correct, since different Bioconductor versions are 
tied to specific R versions (see 
https://bioconductor.org/about/release-announcements/ ). On one version of R I 
am currently using, I get

> BiocManager::install(version = "3.14")
Error: Bioconductor version '3.14' requires R version '4.1'; use
  `BiocManager::install(version = '3.17')` with R version 4.3; see
  https://bioconductor.org/install

The instruction to install a vector of Bioconductor packages is also 
unnecessary for Bioconductor packages in the Imports: or Depends: field of 
, or if one were to pass the argument `dependencies = TRUE` to 
either BiocManager::install() or install.packages() (to get the Suggests: 
packages of  to be installed, as well as Depends:, Imports: and 
LinkingTo:).

Briefly, installation requires R to know the correct repositories. The command

BiocManager::repositories()

Returns a vector of Bioconductor and CRAN repositories relevant to your version 
of R. If one is averse to using BiocManager::install(�RTIGER�), a reasonable 
alternative, though still requiring that the BiocManager package is installed, 
is

install.packages(�RTIGER�, repos = BiocManager::repositories())

Base R also provides a mechanism for specifying Bioconductor repositories, via 
`setRepositories()` called before install.packages(). However, this is not 
recommended because, as can be seen on the web page mentioned above, there are 
two versions of Bioconductor for each version of R � one always gets the �old� 
Bioconductor version, even when a newer version is available.

From: R-package-devel  on behalf of Ivan 
Krylov 
Date: Thursday, March 16, 2023 at 2:15 PM
To: Ruff, Sergej 
Cc: r-package-devel@r-project.org 
Subject: Re: [R-pkg-devel] How to declare Bioconductor Dependencies in the 
Description File of my R Package
On Thu, 16 Mar 2023 17:01:55 +
"Ruff, Sergej"  wrote:

> Last question: How does CRAN work with Bioconductor Dependencies?
> Will CRAN accept limma as a dependency or will my submission be
> rejected?

It's not explicitly spelled out in the CRAN policy
, but
Bioconductor and CRAN are the "mainstream repositories" for the
purposes of the following rule:

>> Packages on which a CRAN package depends should be available from a
>> mainstream repository

(Even non-mainstream repositories are allowed for optional dependencies
if you follow a few additional rules.)

Here's an example of a CRAN package with a strong dependency on a
Bioconductor package: . You
can see the extra instructions for installing the Bioconductor
dependencies in its README.

--
Best regards,
Ivan

__
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

Re: [R-pkg-devel] R package development using GPU based on R package OpenCL

[Martin Morgan]

I�m not particularly experienced with this but wrote a �proof-of-concept� 
skeleton of a package at https://github.com/mtmorgan/ocl . The basics are


  *   Import OpenCL in the DESCRIPTION file
  *   Write OpenCL scripts in inst/ (dnorm implemented in OpenCL)
  *   Use the helper function in R/ocl.R to source the code
  *   Provide a user-friendly interface as in R/examples.R (dnorm_ocl)

Martin

From: R-package-devel  on behalf of 
Quirin Stier 
Date: Tuesday, October 11, 2022 at 10:46 AM
To: r-package-devel@r-project.org 
Subject: [R-pkg-devel] R package development using GPU based on R package OpenCL
Dear members,

I have difficulties packing my OpenCL functions together as a complete R
package. I did not find any exemplary R package building upon the R
OpenCL Package. Currently I can only run the OpenCL functions as was
presented by the OpenCL examples of the OpenCL package itself. So,
assuming I have working OpenCL files, how can I create the MakeVars (or
whatever necessity needs to be done), in order to create a fully
functional R package?

Best regards,

Quirin

__
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

Re: [R-pkg-devel] Checking package dependencies before loading namespace

[Martin Morgan]

Actually, I think the right thing to do is to tell the user what to do ("To use 
this feature, install EBImage following the directions at 
https://bioconductor.org/packages/EBImage') instead of doing it for them.

Martin

From: Tiago Olivoto 
Date: Friday, September 3, 2021 at 2:14 PM
To: Martin Morgan 
Cc: Uwe Ligges , R Package Devel 

Subject: Re: [R-pkg-devel] Checking package dependencies before loading 
namespace
Thanks for your response Martin,
I'm definitely thinking to use BiocManager::install("EBImage") since it is the 
official suggestion of the Bioconductor community. Anyway, I've been learning a 
lot from this discussion. Thanks all!!
Best,
Tiago

Em sex., 3 de set. de 2021 às 12:58, Martin Morgan 
<mailto:mtmorgan.b...@gmail.com> escreveu:
The specific repository you've chosen is not what you want to do. This will 
always install EBImage from Bioconductor version 3.13, but Bioconductor version 
3.13 is only relevant for R-4.1 (see 
https://bioconductor.org/about/release-announcements/)

Personally, I would encourage you to follow the Bioconductor community best 
practice of BiocManager::install("EBImage"). In that way you will get the 
version of EBImage that has been tested with other Bioconductor packages in the 
same release, and on the version of R in use by your user.

If you were to use a specific repository, it should the one that is as good as 
base R can do (this can be different from the version that BiocManager would 
choose because R's release cycle is different from Bioconductor's). I think 
this is most easily accomplished by utils::chooseBioCmirror(), and then 
selecting the 0-Bioconductor repository. That's a lot to tell your users... 
Maybe others in the R community have a better way (the key information is in 
tools:::.BioC_version_associated_with_R_version(), but that is not an exported 
function so not recommended for CRAN packages...)

Martin Morgan

On 9/1/21, 8:13 AM, "R-package-devel on behalf of Tiago Olivoto" 
<mailto:r-package-devel-boun...@r-project.org on behalf of 
mailto:tiagooliv...@gmail.com> wrote:

    Thank you, Duncan and Uwe for the suggestions.
     I followed your instructions and created a function to check for EBImage
    that is only called in an interactive section and, if necessary, ask the
    user to install the package with install.packages("EBImage", repos="
    https://bioconductor.org/packages/3.13/bioc;)

    Best,
    Tiago

    Em qua., 1 de set. de 2021 às 03:53, Uwe Ligges <
    mailto:lig...@statistik.tu-dortmund.de> escreveu:

    > Two more comments.
    >
    > 1. Note that your code only works in interactice mode, not when checking
    > your package as it waits infinitely for the user's choice.
    >
    > 2. I do not see an advantage of installing BiocManager if EBImage is
    > needed, the essential part is simply to select BioC as a repository to
    > install packages from.
    >
    > Best,
    > Uwe Ligges
    >
    >
    > On 31.08.2021 23:33, Duncan Murdoch wrote:
    > > People shouldn't be able to install your package unless the "hard"
    > > dependencies are available.
    > >
    > > If EBImage isn't essential to your package, you should make it a "soft"
    > > dependency by listing it in Suggests and checking for it every time you
    > > use it.
    > >
    > > Duncan Murdoch
    > >
    > > On 31/08/2021 3:20 p.m., Tiago Olivoto wrote:
    > >> Dear all,
    > >> I have a package called pliman
    > >> <https://CRAN.R-project.org/package=pliman>
    > >> which depends on the Bioconductor package EBImage.
    > >>
    > >> When running install.packages("pliman") I get the following warning
    > >>
    > >> Warning in install.packages :  dependency ‘EBImage’ is not available
    > >>
    > >> and thus when loading the package with library(pliman), the following
    > >> error
    > >> occurs
    > >>
    > >> Erro: package or namespace load failed for ‘pliman’ in loadNamespace(i,
    > >> c(lib.loc, .libPaths()), versionCheck = vI[[i]]):
    > >>   there is no package called ‘EBImage’
    > >>
    > >> I created a check function to check if EBImage is available and if
    > >> not, ask
    > >> users if they want to install it
    > >>
    > >> ---
    > >> check_ebi <- function(){
    > >>    if(!requireNamespace("EBImage", quietly = TRUE)) {
    > >>      inst <-
    > >>      switch(menu(c("Yes", "No"), title = "Package {EBImage} required
    > >> but not
    > >> available.\nDo you want to install it now?"),
    

Re: [R-pkg-devel] Checking package dependencies before loading namespace

[Martin Morgan]

The specific repository you've chosen is not what you want to do. This will 
always install EBImage from Bioconductor version 3.13, but Bioconductor version 
3.13 is only relevant for R-4.1 (see 
https://bioconductor.org/about/release-announcements/)

Personally, I would encourage you to follow the Bioconductor community best 
practice of BiocManager::install("EBImage"). In that way you will get the 
version of EBImage that has been tested with other Bioconductor packages in the 
same release, and on the version of R in use by your user.

If you were to use a specific repository, it should the one that is as good as 
base R can do (this can be different from the version that BiocManager would 
choose because R's release cycle is different from Bioconductor's). I think 
this is most easily accomplished by utils::chooseBioCmirror(), and then 
selecting the 0-Bioconductor repository. That's a lot to tell your users... 
Maybe others in the R community have a better way (the key information is in 
tools:::.BioC_version_associated_with_R_version(), but that is not an exported 
function so not recommended for CRAN packages...)

Martin Morgan

On 9/1/21, 8:13 AM, "R-package-devel on behalf of Tiago Olivoto" 
 
wrote:

Thank you, Duncan and Uwe for the suggestions.
 I followed your instructions and created a function to check for EBImage
that is only called in an interactive section and, if necessary, ask the
user to install the package with install.packages("EBImage", repos="
https://bioconductor.org/packages/3.13/bioc;)

Best,
Tiago

Em qua., 1 de set. de 2021 às 03:53, Uwe Ligges <
lig...@statistik.tu-dortmund.de> escreveu:

> Two more comments.
>
> 1. Note that your code only works in interactice mode, not when checking
> your package as it waits infinitely for the user's choice.
>
> 2. I do not see an advantage of installing BiocManager if EBImage is
> needed, the essential part is simply to select BioC as a repository to
> install packages from.
>
> Best,
> Uwe Ligges
>
>
> On 31.08.2021 23:33, Duncan Murdoch wrote:
> > People shouldn't be able to install your package unless the "hard"
> > dependencies are available.
> >
> > If EBImage isn't essential to your package, you should make it a "soft"
> > dependency by listing it in Suggests and checking for it every time you
> > use it.
> >
> > Duncan Murdoch
> >
> > On 31/08/2021 3:20 p.m., Tiago Olivoto wrote:
> >> Dear all,
> >> I have a package called pliman
> >> <https://CRAN.R-project.org/package=pliman>
> >> which depends on the Bioconductor package EBImage.
> >>
> >> When running install.packages("pliman") I get the following warning
> >>
> >> Warning in install.packages :  dependency ‘EBImage’ is not available
> >>
> >> and thus when loading the package with library(pliman), the following
> >> error
> >> occurs
> >>
> >> Erro: package or namespace load failed for ‘pliman’ in loadNamespace(i,
> >> c(lib.loc, .libPaths()), versionCheck = vI[[i]]):
> >>   there is no package called ‘EBImage’
> >>
> >> I created a check function to check if EBImage is available and if
> >> not, ask
> >> users if they want to install it
> >>
> >> ---
> >> check_ebi <- function(){
> >>if(!requireNamespace("EBImage", quietly = TRUE)) {
> >>  inst <-
> >>  switch(menu(c("Yes", "No"), title = "Package {EBImage} required
> >> but not
> >> available.\nDo you want to install it now?"),
> >> "yes", "no")
> >>  if(inst == "yes"){
> >>if (!requireNamespace("BiocManager", quietly = TRUE)){
> >>  install.packages("BiocManager")
> >>}
> >>BiocManager::install("EBImage", ask = FALSE, update = FALSE)
> >>  } else{
> >>message("To use {pliman}, first install {EBImage} with
> >> 'BiocManager::install(\"EBImage\")'.")
> >>  }
> >>}
> >> }
> >> ---
> >>
> >> Is there any way to run this function prior to namespace loading? I
> tried
> >> putting check_ebi() into .onLoad() but the same error occurs.

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] Old version of rtracklayer on a single check server

[Martin Morgan]

It is wrong to say that ‘it will never be solved for R.4.0.0’. Rather, ‘it will 
never be a problem for R.4.0.0’.

rtracklayer 1.51.5 was only ever built, checked, distributed (and installed in 
a correctly configured system, using the rules of install.packages and 
tools:::.BioC_version_associated_with_R_version(), or of 
BiocManager::install()) on R-devel (now R-4-1-0-branch). So R-4.0.* has never 
supported version 1.51.5 of rtracklayer.

No Bioconductor package built on R-4.0.* would propagate (be visible to 
install.packages()) with a dependency on rtracklayer-1.51.5. A CRAN package 
with a dependency on rtracklayer-1.51.5 (this is hypothetical, I do not believe 
it is the case for CNVScope), would be correctly flagged as an error – this 
version of rtracklayer will never be available on R-4.0.*, and the CRAN package 
author would have to re-assess the reasons for specifying the dependency for 
that version of R.

Bioconductor does rarely produce ‘impossible’ dependencies particularly in the 
Bioconductor ‘devel’ branch (when a package builds and checks even though one 
of its dependencies builds but does not pass check), but these are transient 
and an artifact of the Bioconductor  build system – the lagging package Is 
usually promptly updated so the published dependency is satisfied.


From: Henrik Bengtsson 
Date: Tuesday, May 18, 2021 at 2:41 PM
To: Martin Morgan 
Cc: "Dalgleish, James (NIH/NCI) [F]" , 
"r-package-devel@r-project.org" 
Subject: Re: [R-pkg-devel] Old version of rtracklayer on a single check server

I stand corrected about the R-devel version (and now R 4.1.0) on CRAN.

However, isn't it the case that it will never be solved for R 4.0.0 (to become 
R-oldrel on CRAN) and CRAN will keep reporting an error on MS Windows there 
because https://bioconductor.org/packages/3.12/bioc/html/rtracklayer.html 
provides only an older version for MS Windows?

If so, an alternative to relying on Suggests is to make the package depend on R 
(>= 4.1.0).

/Henrik

On Tue, May 18, 2021, 09:08 Martin Morgan 
mailto:mtmorgan.b...@gmail.com>> wrote:
That’s not correct Henrik.

CRAN follows CRAN rules for installing packages, so uses 
tools:::BioC_version_for_R_version(). For R-devel we have

> R.version.string
[1] "R Under development (unstable) (2021-05-18 r80323)"
> tools:::.BioC_version_associated_with_R_version()
[1] '3.13'

For this version of Bioconductor, the rtracklayer version (from 
https://bioconductor.org/packages/3.13/rtracklayer, or 
`available.packages(repos = 
"https://bioconductor.org/packages/3.13/bioc;)["rtracklayer", "Version"]`) is 
1.51.5.

So the r-devel-windows-ix86+x86_64 builder mentioned in the post has the wrong 
version of rtracklayer for R-devel.

Martin Morgan

On 5/18/21, 11:49 AM, "R-package-devel on behalf of Henrik Bengtsson" 
mailto:r-package-devel-boun...@r-project.org>
 on behalf of henrik.bengts...@gmail.com<mailto:henrik.bengts...@gmail.com>> 
wrote:

It's a problem with Bioconductor and a broken release history of
'rtracklayer' on MS Windows (e.g.
https://bioconductor.org/packages/3.12/bioc/html/rtracklayer.html)
plus how each Bioconductor version is tied to a specific R version.
In other words, even if they fix it in Bioconductor 3.13 (for R
4.1.0), it can't be fixed in Bioconductor 3.12 (for R 4.0.0), so
you're package will keep failing on Windows for R 4.0.0.  The reason
why it can't be fixed in Bioconductor 3.12 is that they have now
frozen that release forever.

Because of this, I suspect the only solution is to make 'rtracklayer'
an optional package, i.e. move it to Suggests: and update all your
code to run conditionally of that package being available. I recommend
you reach out to the bioc-devel mailing list for advice.

/Henrik

On Tue, May 18, 2021 at 4:33 AM Dalgleish, James (NIH/NCI) [F] via
R-package-devel 
mailto:r-package-devel@r-project.org>> wrote:
>
> To any who might have an idea:
>
> I've been reading several posts in the digest about dependency version 
issues on the check servers and I'm having my own issue, which I can't solve 
because I can't upgrade the check server's package version:
> * installing *source* package 'CNVScope' ...
> ** using staged installation
> ** R
> ** data
> *** moving datasets to lazyload DB
> ** inst
> ** byte-compile and prepare package for lazy loading
> Warning: multiple methods tables found for 'export'
> Error in loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()), 
versionCheck = vI[[j]]) :
>   namespace 'rtracklayer' 1.48.0 is already loaded, but >= 1.51.5 is 
required
> Calls:  ... namespaceImportFrom -> asNamespace -> loadNamespace
> Execution halted
> ERROR: lazy loading failed for package 'CNVScope'
> *

Re: [R-pkg-devel] Old version of rtracklayer on a single check server

[Martin Morgan]

That’s not correct Henrik.

CRAN follows CRAN rules for installing packages, so uses 
tools:::BioC_version_for_R_version(). For R-devel we have

> R.version.string
[1] "R Under development (unstable) (2021-05-18 r80323)"
> tools:::.BioC_version_associated_with_R_version()
[1] '3.13'

For this version of Bioconductor, the rtracklayer version (from 
https://bioconductor.org/packages/3.13/rtracklayer, or 
`available.packages(repos = 
"https://bioconductor.org/packages/3.13/bioc;)["rtracklayer", "Version"]`) is 
1.51.5. 

So the r-devel-windows-ix86+x86_64 builder mentioned in the post has the wrong 
version of rtracklayer for R-devel.

Martin Morgan

On 5/18/21, 11:49 AM, "R-package-devel on behalf of Henrik Bengtsson" 
 
wrote:

It's a problem with Bioconductor and a broken release history of
'rtracklayer' on MS Windows (e.g.
https://bioconductor.org/packages/3.12/bioc/html/rtracklayer.html)
plus how each Bioconductor version is tied to a specific R version.
In other words, even if they fix it in Bioconductor 3.13 (for R
4.1.0), it can't be fixed in Bioconductor 3.12 (for R 4.0.0), so
you're package will keep failing on Windows for R 4.0.0.  The reason
why it can't be fixed in Bioconductor 3.12 is that they have now
frozen that release forever.

Because of this, I suspect the only solution is to make 'rtracklayer'
an optional package, i.e. move it to Suggests: and update all your
code to run conditionally of that package being available. I recommend
you reach out to the bioc-devel mailing list for advice.

/Henrik

On Tue, May 18, 2021 at 4:33 AM Dalgleish, James (NIH/NCI) [F] via
R-package-devel  wrote:
>
> To any who might have an idea:
>
> I've been reading several posts in the digest about dependency version 
issues on the check servers and I'm having my own issue, which I can't solve 
because I can't upgrade the check server's package version:
> * installing *source* package 'CNVScope' ...
> ** using staged installation
> ** R
> ** data
> *** moving datasets to lazyload DB
> ** inst
> ** byte-compile and prepare package for lazy loading
> Warning: multiple methods tables found for 'export'
> Error in loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()), 
versionCheck = vI[[j]]) :
>   namespace 'rtracklayer' 1.48.0 is already loaded, but >= 1.51.5 is 
required
> Calls:  ... namespaceImportFrom -> asNamespace -> loadNamespace
> Execution halted
> ERROR: lazy loading failed for package 'CNVScope'
> * removing 'd:/RCompile/CRANguest/R-devel/lib/CNVScope'
>
> These errors tend to be check server dependent (only occurs on 
r-devel-windows-ix86+x86_64<https://cran.r-project.org/web/checks/check_flavors.html#r-devel-windows-ix86_x86_64>)
 and I'm just trying to make the small change to closeAllConnections() that was 
asked earlier of maintainers by Kurt Hornik and the CRAN team, but I can't 
because of this old package version on the devel check server, which has the 
same error:
> 
https://win-builder.r-project.org/incoming_pretest/CNVScope_3.5.7_20210518_062953/Windows/00check.log
> 
https://win-builder.r-project.org/incoming_pretest/CNVScope_3.5.7_20210518_062953/Windows/00install.out
>
> Is there any way around this? I notice the maintainer of the 'gtsummary' 
package had a similar issue:
>
> "> I am trying to make a release that depends on gt v0.3.0, but I get an 
error
>
> > when I test the package on Windows Dev `devtools::check_win_devel()` 
that
>
> > the gt package is available but it's an unsuitable version.  Does anyone
>
> > know why the gt v0.3.0 is unavailable?"
>
>
>
> I'm open to any suggestions, but can't see a way around this issue from 
my end without the ability to service the check server.
>
>
> Thanks,
> James Dalgleish
> Cancer Genetics Branch,
> Center for Cancer Research,
> National Cancer Institute,
> National Institutes of Health,
> Bethesda, MD
>
>
> [[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-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] rtracklayer installation problems

[Martin Morgan]

(sorry, too quick on the return key)

From the Bioconductor 'devel' (3.13, used with R-devel) 'landing page' for 
rtracklayer

https://bioconductor.org/packages/devel/rtracklayer

The 'build' badge is red; clicking on it shows a build system problem with 
rtracklayer on Windows. Scrolling on the landing page to the bottom shows

Source Package  rtracklayer_1.51.5.tar.gz
Windows Binary  
macOS 10.13 (High Sierra)   rtracklayer_1.51.5.tgz

so there is currently no Windows binary available. This is in the hands of the 
rtracklayer maintainer; there is a very high likelihood that it will be fixed, 
so either be patient or ask the rtracklayer maintainer directly to address this 
by, e.g., opening an issue at https://github.com/lawremi/rtracklayer

Martin Morgan


On 4/7/21, 6:32 AM, "R-package-devel on behalf of Gordon Brown" 
 wrote:

Hi, Rosario,

The message is telling you that you need to install the development header 
files for glibc on your computer.  This is a set of files that are needed for 
building some kinds of software, but are not installed by default.  Are you 
working on some sort of Linux machine?  On Centos 8, the relevant package to 
install is called "glibc-headers".  On Ubuntu 20.04 it's "libc6-dev".  You'd 
need to run a command in the shell, something like:

Centos:
> sudo dnf install glibc-headers
or
> sudo yum install glibc-headers

Ubuntu/Debian:
> sudo apt install libc6-dev

If it's Windows or Mac, I can't help...

If you don't have root access on your host, or the above doesn't make sense 
to you, you will need to talk to whoever administers your computing 
environment, asking them to install the relevant package.

Hope this helps.

 - Gord


On 20210407, 11:03, "R-package-devel on behalf of rosario.avo...@unina.it" 
 
wrote:

Hi everyone,



I hope this is the right e-mail I should have used; this is the first 
time
that I ask for help with R!

Yesterday, I installed the devel version of R (4.1) as I need to use a
package (RiboDiPa) which only works for this version.

The package requires, among the others, the package "rtracklayer". Since
yesterday I am struggling trying to install rtracklayer for devel 
version
without success.

Below you can find the final message I got before the installation 
stops.
Any idea of what might be the reason why I cannot install rtracklayer? 



ucsc/udc.c:46:10: fatal error: sys/mman.h: No such file or directory

#include 

  ^~~~

compilation terminated.

make: *** 
[https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fMakevars.win%3a16=E,1,aB4mtmdcaXh3y_rFcDWiXKtEvYZoLA3GcTOtz2EAwNVyTaBV0cLYVfIMvPNYj-c9QK7LiaHqut3FcMfCLlVShgqSAdXj_xGXP8nS49zX7vVKE9rNPhmLmWDTnyU,=1:
 ucsc/udc.o] Error 1

ERROR: compilation failed for package 'rtracklayer'

* removing 'C:/Users/Rosario/Documents/R/win-library/4.1/rtracklayer'



If you need any other information please, do not hesitate to ask.

Thank you in advance for your help!



Best,

Rosario





Rosario Avolio, PhD

Researcher

Department of Molecular Medicine and Medical Biotechnology

Via Pansini, 5

19/A Building

80131 Napoli, Italy

email:  <mailto:rosario.avo...@unina.it> rosario.avo...@unina.it

phone: +39 081 746 31 39




[[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-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] rtracklayer installation problems

[Martin Morgan]

From the Bioconductor 'devel' (3.13, used with R-devel) 'landing page' for 
rtracklayer

https://bioconductor.org/packages/devel/rtracklayer

The 'build' badge is red; clicking on it shows a build system problem with 
rtracklayer on Windows. Scrolling on the landing page to the bottom shows

Source Package  rtracklayer_1.51.5.tar.gz
Windows Binary  
macOS 10.13 (High Sierra)   rtracklayer_1.51.5.tgz
Source Repository   



On 4/7/21, 6:32 AM, "R-package-devel on behalf of Gordon Brown" 
 wrote:

Hi, Rosario,

The message is telling you that you need to install the development header 
files for glibc on your computer.  This is a set of files that are needed for 
building some kinds of software, but are not installed by default.  Are you 
working on some sort of Linux machine?  On Centos 8, the relevant package to 
install is called "glibc-headers".  On Ubuntu 20.04 it's "libc6-dev".  You'd 
need to run a command in the shell, something like:

Centos:
> sudo dnf install glibc-headers
or
> sudo yum install glibc-headers

Ubuntu/Debian:
> sudo apt install libc6-dev

If it's Windows or Mac, I can't help...

If you don't have root access on your host, or the above doesn't make sense 
to you, you will need to talk to whoever administers your computing 
environment, asking them to install the relevant package.

Hope this helps.

 - Gord


On 20210407, 11:03, "R-package-devel on behalf of rosario.avo...@unina.it" 
 
wrote:

Hi everyone,



I hope this is the right e-mail I should have used; this is the first 
time
that I ask for help with R!

Yesterday, I installed the devel version of R (4.1) as I need to use a
package (RiboDiPa) which only works for this version.

The package requires, among the others, the package "rtracklayer". Since
yesterday I am struggling trying to install rtracklayer for devel 
version
without success.

Below you can find the final message I got before the installation 
stops.
Any idea of what might be the reason why I cannot install rtracklayer? 



ucsc/udc.c:46:10: fatal error: sys/mman.h: No such file or directory

#include 

  ^~~~

compilation terminated.

make: *** 
[https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fMakevars.win%3a16=E,1,aB4mtmdcaXh3y_rFcDWiXKtEvYZoLA3GcTOtz2EAwNVyTaBV0cLYVfIMvPNYj-c9QK7LiaHqut3FcMfCLlVShgqSAdXj_xGXP8nS49zX7vVKE9rNPhmLmWDTnyU,=1:
 ucsc/udc.o] Error 1

ERROR: compilation failed for package 'rtracklayer'

* removing 'C:/Users/Rosario/Documents/R/win-library/4.1/rtracklayer'



If you need any other information please, do not hesitate to ask.

Thank you in advance for your help!



Best,

Rosario





Rosario Avolio, PhD

Researcher

Department of Molecular Medicine and Medical Biotechnology

Via Pansini, 5

19/A Building

80131 Napoli, Italy

email:   rosario.avo...@unina.it

phone: +39 081 746 31 39




[[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-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Strange error from CRAN on package submission

[Martin Morgan]

This seems more like a problem with the CRAN test machine, with the movMF 
package installed with flexmix available but loaded with flexmix not available, 
maybe interacting with a caching mechanism used by the methods package to avoid 
re-computing methods tables? Otherwise how would movMF ever know to create the 
flexmix class / method?

It seems like this could cause problems for the user if they installed movMV 
with flexmix available, but removed flexmix. This seems like a subtler 
variation of 'I installed package A but then removed dependency B and now A 
doesn't work', which could be a bug in R's remove.packages() but

I tried to emulate the scenario of installing movMF and then removing flexmix 
in an interactive session, and then looking for the warning reported below. I 
was not successful, but the build report with the error is no longer available 
so I don't know what I'm looking for...

Martin Morgan

On 11/11/20, 4:44 PM, "R-package-devel on behalf of Duncan Murdoch" 
 
wrote:

Here's what I think is happening.

In the movMF:::.onLoad function there's a test whether flexmix is 
installed.  If found, then it is loaded and some methods are set.  (I'm 
not sure what caused flexmix to be installed:  I didn't intentionally 
install it, but it ended up in there when I installed enough stuff to 
check Mercator.)

In the R-devel --as-cran checks, some checks are run with only strong 
dependencies of your package visible.  Somehow I think that .onLoad 
function sees flexmix and loads it, but then some other part of the 
check can't see it.

A workaround is to add flexmix to your Imports clause.  This is a strong 
enough dependency to make it visible, and the error goes away.

HOWEVER, to me this is pretty clearly an R-devel bug:  you have no 
control over methods set by packages that you don't even use, so you 
shouldn't have to change your dependency lists if one of them sets a 
method that you're using.

Duncan Murdoch

On 11/11/2020 3:31 p.m., Kevin R. Coombes wrote:
> Oh, I forgot to mention explicitly that checking (with --as-cran) on the
> development version of R on Windows also produces no errors or warnings.
> 
> On 11/11/2020 1:39 PM, Kevin R. Coombes wrote:
>> Hi Duncan,
>>
>> I just sent a longer version of this message, but it looks to me like
>> the underlying issue is the fact that flexmix and Mercator both define
>> and export "show" methods for their S4 classes.  What confuses me is
>> why the NAMESPACE of a package that is merely Suggest'ed by something
>> several layers down the hierarchy should get attached and cause an
>> issue like this one. (The attached NAMESPACE happens in current
>> versions of R.)
>>
>> Thanks,
>>Kevin
>>
>> On 11/11/2020 1:07 PM, Duncan Murdoch wrote:
>>> Okay, I've tried testing on my Mac with R 4.0.3 and R-devel for the
>>> new one, 4.0.3 for the CRAN version.
>>>
>>> I'm not seeing any check error with the CRAN version.  I get an error
>>> trying to check 0.11.4 from R-forge because I don't have flexmix
>>> installed.  If I take flexmix out of the Suggests list, it checks
>>> with no error on 4.0.3, but I get the error you saw on R-devel when
>>> checked with --as-cran.
>>>
>>> I tried debugging this, and narrowed it down a bit.  It happens when
>>> your package is installed, in particular in the do_install_source()
>>> function in src/library/tools/R/install.R. But that function runs a
>>> new R instance, and I didn't get to debugging that.  I'll try again
>>> later today if nobody else figures it out.
>>>
>>> Duncan Murdoch
>>>
>>>
>>>
>>>
>>> On 11/11/2020 12:03 p.m., Kevin R. Coombes wrote:
>>>> Hi Duncan,
>>>>
>>>> Oops; I didn't realize I had forgotten to push updates to the OOMPA web
>>>> site.
>>>>
>>>> The code for Mercator is contained as part of the Thresher project in
>>>> the subversion repository on R-Forge.
>>>> (https://r-forge.r-project.org/projects/thresher/) It's under
>>>> pkg/Mercator below that URL
>>>>
>>>> Thanks,
>>>>  Kevin
>>>>
>>>> On 11/11/2020 11:30 AM, Duncan Murdoch wrote:
>>>>> Uwe suggested you suggest flexmix, but I see below you already tried
>>>>> that.
>>>>>
>>>>> I'd like to take a lo

Re: [R-pkg-devel] Use of `:::` in a package for code run in a parallel cluster

[Martin Morgan]

At least in the 'parallel' package

library(parallel)
cl = makePSOCKcluster(2)

and because of the nature of the R language, the entire namespace is exported, 
analogous to

baz <- local({
foo <- function() 2
function(...) foo()
})

so making a package function baz available makes all functions in the package 
available -- a function in the package already has access to other functions in 
the namespace, whether those functions are exported or not, so there is no need 
to use :::.

> parSapply(1:2, baz)
[1] 2 2

This is in contrast to what one might expect from exploring things on the 
command line, where foo is defined in the global environment and, by 
convention, the global environment is not serialized to the workers

> foo <- function() 1
> bar <- function(...) foo()
> parLapply(cl, 1:2, bar)
Error in checkForRemoteErrors(val) : 
  2 nodes produced errors; first error: could not find function "foo"

Do you really need to use `:::`?

Martin Morgan



On 9/13/20, 3:52 PM, "R-package-devel on behalf of David Kepplinger" 
 
wrote:

Dear list members,

I submitted an update for my package and got automatically rejected by the
incoming checks (as expected from my own checks) for using `:::` calls to
access the package's namespace.
"There are ::: calls to the package's namespace in its code. A package
*almost* never needs to use ::: for its own objects:…" (emphasis mine)

This was a conscious decision on my part as the package runs code on a
user-supplied parallel cluster and I consider cluster-exporting the
required functions a no-go as it would potentially overwrite objects in the
clusters R sessions. The package code does not own the cluster and hence
the R sessions. Therefore overwriting objects could potentially lead to
unintended behaviour which is opaque to the user and difficult to debug.

Another solution to circumvent the R CMD check note is to export the
functions to the public namespace but mark them as internal. This was also
suggested in another thread on this mailing list (c.f. "Etiquette for
package submissions that do not automatically pass checks?"). I do not
agree with this work-around as the methods are indeed internal and should
never be used by users. Exporting truly internal functions for the sake of
satisfying R CMD check is a bad argument, in particular if there is a
clean, well-documented, solution by using `:::`.

I argue `:::` is the only clean solution to this problem and no dirty
work-arounds are necessary. This is a prime example of where `:::` is
actually useful and needed inside a package. If the R community disagrees,
I think R CMD check should at least emit a WARNING instead of a NOTE and
elaborate on the problem and accepted work-arounds in "Writing R
extensions". Or keep emitting a NOTE but listing those nebulous reasons
where `:::` would be tolerated inside a package. Having more transparent
criteria for submitting to CRAN would be really helpful to the entire R
community and probably also reduce the traffic on this mailing list.

Best,
David

[[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] bioconductor package required but not available

[Martin Morgan]

Here is the build report for KEGGgraph

http://bioconductor.org/packages/release/bioc/html/KEGGgraph.html

where it builds, and is available, across all platforms. This does not seem to 
be a Bioconductor problem, but rather a CRAN configuration issue.

Martin Morgan
Bioconductor

On 9/1/20, 12:05 PM, "R-package-devel on behalf of Jendoubi Bedhiafi, Takoua" 
 wrote:

Hi all,

All checks for my updated package seem to be all fine except for  
r-release-macos-x86_64 
<https://cran.r-project.org/web/checks/check_flavors.html#r-release-macos-x86_64>
 .
KEGGgraph a bio conductor package is required for my package to run but is 
not available on the platform.

It is however available on the devel version.
Full log below:

https://www.r-project.org/nosvn/R.check/r-release-macos-x86_64/iCARH-00check.html

Does this mean the package might be removed from CRAN?

Thanks in advance,
bw,

Dr. Takoua Jendoubi, PhD, MSc, PGCert ULT, FHEA
Strategic Teaching Fellow in Statistics

Statistics section | Department of Mathematics |
Imperial College London | Room 533 |
South Kensington Campus | London |
SW7 2AZ |


[[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] [R] a question of etiquette

[Martin Morgan]

To present a contrary view...

To me the commentary so far doesn't seem right -- if I were writing an academic 
paper (I personally think this is a good analogy for many R packages) and 
elaborating on the ideas of someone else, I would cite their work but I would 
not add them as an author to my paper. I would not expect the authors of cited 
work to agree with or take responsibility for my work, which is what authorship 
(in the publication domain) implies. In the current case there is no reason to 
think that the author of matlab code would be informed about or willing to 
vouch for the R implementation. Minimally, in an academic setting I would (be 
required to) ask whether the individual wished to be an author. 

Conversely, if an author were to have made a substantive contribution to my 
package, and objected to the content of the package with their name on it, I 
would feel obliged to respect their wishes and, e.g., withdraw or, if permitted 
by licensing, revise or re-publish the paper / package without the author. This 
makes me think carefully about who actually contributed to the package, rather 
than merely whose prior work my package builds upon.

Of course it is necessary to obey licensing terms of the prior work, and 
important to acknowledge, above and beyond the specific licensing terms, the 
contributions individuals make.

Martin Morgan

On 6/2/20, 5:57 AM, "R-package-devel on behalf of Adelchi Azzalini" 
 
wrote:

The point in question does not refer to copying code, but to code 
translation.
Does this make any difference? 
This was the question which I raised.

The phrase "As the code is part of the package now," does not seem to apply 
in this case,
since the code is actually not there.

Also, if the authors of the original code (in Matlab) must be included in 
the Authors@R 
block of the DESCRIPTION file, should they be labelled as "aut", "cbt", or 
what?

Apart from the specific instance  which my earlier question was referring 
to,
the view "As the code is part of the package now, therese are of course now 
also copyright 
holders and authors of your package" opens another question, closely 
related but different,
as it refers to code which is included, not translated. 
The above-quoted sentence appears to say that anyone who has written any
portion of code is an author of the package. In this view, who must be 
labelled "cbt" then?

Best regards

Adelchi


> On 2 Jun 2020, at 01:25, Uwe Ligges  
wrote:
> 
> If you copy code, you have to make sure that you can use it under the 
currrent license of your package, and you have to make sure to declare copright 
holders and authors. As the code is part of the package now, therese are of 
course now also copyright holders and authors of your package.
> 
> Best,
> Uwe Ligges
> 
> On 01.06.2020 23:37, R. Mark Sharp wrote:
>> Adelchi,
>> I have a similar situation where I had made all of the typical academic 
references within the code and documentation for a small but important function 
my package uses. I was asked by the CRAN reviewers to add the author of that 
function to the DESCRIPTION Authors@R section. I added the following:
>> person("Terry", "Therneau", role = c("aut”))
>> Mark
>> R. Mark Sharp, Ph.D.
>> Data Scientist and Biomedical Statistical Consultant
>> 7526 Meadow Green St.
>> San Antonio, TX 78251
>> mobile: 210-218-2868
>> rmsh...@me.com
>>> Begin forwarded message:
>>> 
>>> From: Adelchi Azzalini 
>>> Subject: [R] a question of etiquette
>>> Date: June 1, 2020 at 11:34:00 AM CDT
>>> To: r-h...@r-project.org
>>> 
>>> The new version of a package which I maintain will include a new 
function which I have ported to R from Matlab.
>>> The documentation of this R function indicates the authors of the 
original Matlab code, reference to their paper, URL of the source code.
>>> 
>>> Question: is this adequate, or should I include them as co-authors of 
the package, or as contributors, or what else?
>>> Is there a general policy about this matter?
>>> 
>>> Adelchi Azzalini
>>> http://azzalini.stat.unipd.it/
>>> 
>>> __
>>> r-h...@r-project.org mailing list -- To UNSUBSCRIBE and more, see
>>> https://stat.ethz.ch/mailman/listinfo/r-help
>>> PLEASE do read the posting guide 
http://www.R-project.org/posting-guide.html
>>> and provide commented, minimal, self-contained, reproducible code.
>

Re: [R-pkg-devel] Windows specific install error

[Martin Morgan]

This is the same as

  https://stat.ethz.ch/pipermail/r-package-devel/2020q1/005256.html

and due I believe to stale packages on the CRAN windows builder; the solution 
is I believe on the CRAN side.

Martin Morgan

On 4/7/20, 6:14 PM, "R-package-devel on behalf of Ryan Sartor" 
 wrote:

Hello everyone,

My package seems to pass all the CRAN checks for Linux but fails to install
on Windows. This is the contents of 00install.out:

* installing *source* package 'DiPALM' ...
** using staged installation
** R
** data
** inst
** byte-compile and prepare package for lazy loading
Error: .onLoad failed in loadNamespace() for 'S4Vectors', details:
  call: validObject(.Object)
  error: invalid class "LLint" object: superclass "integer_OR_LLint"
not defined in the environment of the object's class
Execution halted
ERROR: lazy loading failed for package 'DiPALM'
* removing 'd:/RCompile/CRANincoming/R-devel/lib/DiPALM'


If I understand the error, it's saying that the CRAN server cannot
load the S4Vectors package because one of classes it depends on is not
defined. I'm guessing this is a namespace issue? I've taken a few
shots at adding directives to my NAMESPACE file but obviously I don't
know what I'm doing or maybe the error has nothing to do with my
package namespace.

Any insight would be greatly appreciated.

Thank you!

[[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] 'S4Vectors' Error - Bioconductor dependencies

[Martin Morgan]

I guess this is in R-4-0-0 alpha or R-devel, and is due to a change in the 
methods package. This is because a serialized object in S4Vectors needs to be 
re-created, and is likely because package(s) need to be updated. If this is 
your own machine, then you could make sure that

  BiocManager::valid()

returns TRUE and / or update all packages to the most recent available

  BiocManager::install(ask = FALSE)

I'm not sure about CRAN, but am confident that it will eventually clear itself 
up... (not much comfort, I know...)

Martin Morgan

On 3/31/20, 11:42 AM, "R-package-devel on behalf of Kelsey Chetnik" 
 wrote:

Hi,

I am getting a dependencies error and I'm not sure how to solve it. This is
the error:

* installing *source* package 'MetaClean' ...
** using staged installation
** R
** data
*** moving datasets to lazyload DB
** inst
** byte-compile and prepare package for lazy loading
Error: .onLoad failed in loadNamespace() for 'S4Vectors', details:
  call: validObject(.Object)
  error: invalid class "LLint" object: superclass "integer_OR_LLint"
not defined in the environment of the object's class
Execution halted
ERROR: lazy loading failed for package 'MetaClean'
* removing 'd:/RCompile/CRANincoming/R-devel/lib/MetaClean'


I think the issue is related to one of the bioconductor dependencies that I
have (XCMS) not installing properly. I was told that I need to include
biocViews: in my DESCRIPTION file, which I did, but the problem still
persists. Could someone please take a look at my DESCRIPTION to let me know
if there is something wrong / missing:

Package: MetaClean
Title: MetaClean for the Automatic Detection of Low Quality Peaks in
Untargeted Metabolomics Data
Version: 0.1.0
Author: Kelsey Chetnik
Maintainer: Kelsey Chetnik 
Description: This package utilizes 12 peak quality metrics and 9 diverse
machine learning algorithms to build a classifier for the automatic
  assessment of peak integration quality of peaks from untargeted
metabolomics analyses.
Depends: R (>= 3.5.0),
 MLmetrics
biocViews:
Imports:
xcms,
scmamp,
caret,
reshape2,
knitr,
ggplot2,
plotrix,
tools,
utils,
klaR,
fastAdaboost,
rpart,
randomForest,
kernlab,
BiocStyle,
methods,
S4Vectors
License: GPL-3
Encoding: UTF-8
LazyData: true
RoxygenNote: 7.1.0
VignetteBuilder: knitr

I'm stuck because I'm able to compile and run the package on my machine
(macOS) and a local windows machine without any ERRORS, WARNINGS, or NOTES
but I keep getting this error when submitting to CRAN.

Could someone please help me with this?

Thanks,
Kelsey

[[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] Fwd: Re: [CRAN-pretest-archived] CRAN submission SSLR 0.9.0

[Martin Morgan]

After running R CMD check SSLR_0.9.0.tar.gz there is a file 
SSLR.Rcheck/SSLR-Ex.R. Try running that

  R -f SSLR.Rcheck/SSLR-Ex.R

my guess is that somewhere else in the examples you load a package that has a 
generic 'fit' that masks SSLR::fit in your package, so R is not able to find 
your method on the tidymoodels::fit generic.

tidymodels would seem to be a good candidate for this, with perhaps some of the 
search path management done by in SSLR-Ex.R meaning that the mask is not 
reported by tidymodels. Also running the SSLR-Ex.R script used during check 
means effectively

  library(SSLR)
  library(tidymodels)

(tidymodels::fit masks SSLR::fit) whereas running just the example gives

  library(tidymodels)
  library(SSLR)

(SSLR::fit masks tidymodels::fit).

Hmm, after taking the time to tidymodels I see

> fit
function (object, ...)
{
UseMethod("fit")
}



so apparently there is a generics package that defines 'fit'... if you're 
playing in the tidyverse then it seems like you should @importFrom generics fit 
and @export fit.

Martin Morgan

On 3/11/20, 1:50 PM, "R-package-devel on behalf of Henrik Bengtsson" 
 
wrote:

'fpalomares', it's not clear if you can reproduce this locally or not,
but make sure you can reproduce it locally.  I could using:

R CMD check --as-cran SSLR_0.9.0.tar.gz

with R 3.6.3 on Ubuntu 18.04.  In other words, this is neither a
problem with the CRAN incoming checks nor win-builder.

Yes, I agree, at a first glance, this looks odd because:

> library(SSLR)
> fit
function (object, ...)
{
UseMethod("fit")
}


> methods("fit")
[1] fit,onlearn-method fit.model_sslr
see '?methods' for accessing help and source code

Neither

$ Rscript -e 'example("COREG", package = "SSLR")'

nor

> example("COREG", package = "SSLR")

in an interactive session produce the error.

For troubleshooting, I'd added a:

print(methods("fit"))

before

m <- COREG(max.iter = 2) %>% fit(class ~ ., data = train)

I'd also try rewriting that without %>%, e.g. something like

a <- COREG(max.iter = 2)
b <- fit(class ~ a, data = train)

to see if that makes a difference.

My $.02

/Henrik

On Wed, Mar 11, 2020 at 8:13 AM Duncan Murdoch  
wrote:
>
> Uwe Ligges answered you yesterday on this question.
>
> Duncan Murdoch
>
> On 11/03/2020 7:39 a.m., fpaloma...@correo.ugr.es wrote:
> > Hi,
> >
> > I dont know how to fix this problem:
> > https://win-builder.r-project.org/VK8P07E1QHFA/
> >
> > The error is:
> >
> > Error in UseMethod("fit") :
> > no applicable method for 'fit' applied to an object of class
> > "model_sslr"
> >
> > I check with my platform Windows 10 Home and I dont have problems
> >
> > The code used is:
> >
> > #' fit
> > #' @title fit object
> > #' @param object object
> > #' @param ... other parameters to be passed
> > #' @export
> > fit <- function(object, ...){
> > UseMethod("fit")
> > }
> >
> > #' @title Fit with formula and data
> > #' @description Funtion to fit through the formula
> > #' @param object is the model
> > #' @param formula is the formula
> > #' @param data is the total data train
> > #' @param ... unused in this case
> > #' @importFrom rlang quos
> > #' @export fit.model_sslr
> > #' @export
> > fit.model_sslr <- function(object, formula = NULL, data = NULL, ...) {
> >
> > dots <- quos(...)
> >
> >
> > if (all(c("x", "y") %in% names(dots)))
> >   rlang::abort("`fit.model_sslr()` is for the formula methods. Use
> > `fit_xy()` instead.")
> >
> > fit_form_interface <- check_form_interface(formula, data)
> >
> > x_and_y <- get_x_y(formula, data)
> >
> > eval_env <- rlang::env()
> > eval_env$x <- x_and_y$x
> > eval_env$y <- x_and_y$y
> >
> > fit_interface <- check_xy_interface(eval_env$x, eval_env$y)
> >
> > elapsed <- system.time(model <- object$fit_function(eval_env$x,
> > eval_env$y))
> >
> >
> > 
new_model_sslr_fitted(model,class(model),object$args,colnames(eval_env$x),elapsed,formula)
> >

Re: [R-pkg-devel] R CMD build hanging for some but not all packages

[Martin Morgan]

I don't have direct experience or responsibility for this code, but it seems 
like R CMD build could instead create a 'whitelist' of files to copy to the 
build location, and do that rather than copying everything and removing things 
that are to be ignored. The basis for a patch might be somewhere in the 
vicinity of

  
https://github.com/wch/r-source/blob/eb84b52444c4afff936852e11233ee84e26eaef1/src/library/tools/R/build.R#L978-L1051

I'm not sure about the reasons for the current approach, though maybe it is 
simpler to implement, more performant, or maybe handles edge cases (like long 
path names or movement across volumes?) better.

Martin Morgan

On 2/11/20, 9:31 AM, "R-package-devel on behalf of Gábor Csárdi" 
 
wrote:

It is actually rather complicated, because .Rbuildignore can have
regular expressions, that refer to files or directories, and for the
latter you need to ignore the whole directory. You can look up in the
R source code how R does it, maybe you can reuse that code.

Here is a quick and dirty function that does it, mostly based on code
from the remotes package. It is very slow for me currently, mainly
because my .git directory has thousands of files. Still faster than
copying a huge directory I guess.

Speeding it up is left as an exercise. :) I think doing a manual
filtering for /.git initially would probably make it fast enough. Oh,
it is also not super tested. :)

without_ignored <- function(path = ".",
extra = c("^\\.git$", "^\\.gitignore$")) {
  paths <- dir(path, recursive = TRUE, all.files = TRUE)
  ignore_file <- file.path(path, ".Rbuildignore")
  ignore <- c(extra, tools:::get_exclude_patterns())

  if (file.exists(ignore_file)) {
ignore <- c(ignore, readLines(ignore_file, warn = FALSE))
  }

  vlapply <- function(X, FUN, ..., USE.NAMES = TRUE) {
vapply(X, FUN, logical(1L), ..., USE.NAMES = USE.NAMES)
  }

  matches_ignores <- function(x) {
any(vlapply(ignore, grepl, x, perl = TRUE, ignore.case = TRUE))
  }

  directories <- function(paths) {
dirs <- unique(dirname(paths))
out <- dirs[dirs != "."]
while(length(dirs) > 0 && any(dirs != ".")) {
  out <- unique(c(out, dirs[dirs != "."]))
  dirs <- unique(dirname(dirs))
}
sort(out)
  }

  # We need to search for the paths as well as directories in the path, so
  # `^foo$` matches `foo/bar`
  should_ignore <- function(path) {
any(vlapply(c(path, directories(path)), matches_ignores))
  }

  paths[! vlapply(paths, should_ignore)]
}

Gabor

On Tue, Feb 11, 2020 at 2:23 PM Ben Bolker  wrote:
>
>
>Something like file.copy( setdiff(list.files(recursive=TRUE)),
> scan(".Rbuildignore", what=character())),  to = destdir) ?
>
> On 2020-02-11 8:50 a.m., Rainer Krug wrote:
> > Thinking about it - what would be the easiest way, to copy the package, 
excluding files in .Rbuidignore, into the temp directory?
> >
> > I would like to use directly the .Rbuildignore file, to exclude the 
files from copying.
> >
> > Any suggestions?
> >
> >
> >> On 11 Feb 2020, at 10:20, Rainer M Krug  wrote:
> >>
> >>
> >>
> >>> On 11 Feb 2020, at 09:54, Gábor Csárdi  wrote:
> >>>
> >>> On Tue, Feb 11, 2020 at 8:52 AM Rainer M Krug  wrote:
> >>>> On 11 Feb 2020, at 09:42, Gábor Csárdi  
wrote:
> >>>> On Tue, Feb 11, 2020 at 8:38 AM Rainer M Krug  
wrote:
> >>>> On 10 Feb 2020, at 17:58, Gábor Csárdi  
wrote:
> >>>>
> >>>> Maybe you have large, ignored files in the package directory? R first
> >>>> creates a copy of the whole directory and only applies 
`.Rbuildignore`
> >>>> after that.
> >>>>
> >>>> THANKS - you solved my question without me having to answer it. As I 
am using a makefile to build the package, I can easily rename the ignored 
directories before calling build.
> >>>>
> >>>> But the question is why are these ignored directories scanned before 
building the package? They should be ignored anyway?
> >>>>
> >>>> Rainer
> >>>>
> >>>>
> >>>> A makefile is a good idea, but I would rather move the files that are
> >>>> needed to a temporary directory, instead of temporarily renaming
> >>>>

Re: [R-pkg-devel] Unable to reproduce reported problems. Docker image?

[Martin Morgan]

it probably makes sense to more directly indicate what package is causing 
problems (e.g., sharing the location of a public repository of the source) and 
the nature of the error (cut-and-paste the check output here?). Likely this 
will lead both to insight into the problem being flagged by the builder, and 
the reason why you are not able to reproduce it.

Martin Morgan 

On 1/31/20, 9:04 AM, "R-package-devel on behalf of Dirk Eddelbuettel" 
 wrote:


On 31 January 2020 at 09:11, Borini, Stefano wrote:
| Thanks. What is the recommended strategy in this case? Keep submitting 
and patching until it passes?

Standard debugging, and (as Uwe already said) win-builder for that OS, rhub
for others, and asking here, ...  Imperfect, but doable.

It would be so nice to have actual Docker containers to reproduce issues.
Maybe one day.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

__
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] CRAN cannot find libraries on Windows

[Martin Morgan]

what are the correct paths?

On 1/27/20, 3:32 PM, "R-package-devel on behalf of Uwe Ligges" 
 wrote:

Thanks, one suspicious part from the log below is

-LC:/extsoft/lib/i386

which is clearly not in any variable we define on CRAN.

Looking close shows that
 > Rhtslib::pkgconfig("PKG_LIBS")

gives

'D:/RCompile/CRANpkg/lib/4.0/Rhtslib/usrlib/x64/libhts.a' 
-LC:/extsoft/lib/x64 -lcurl -lrtmp -lssl -lssh2 -lcrypto -lgdi32 -lz 
-lws2_32 -lwldap32 -lwinmm

and that is wrong as -LC:/extsoft/lib/i386 or C:/extsoft/lib/x64 are not 
directories where the software is installed on winbuilder.

Pls use the directories the other packages are using, too.

Best,
Uwe Ligges











On 26.01.2020 22:40, Lucas Nell wrote:
> Hello all,
> 
> My package (source here ) no 
longer
> compiles on a standard Windows installation (see truncated install log
> below). The problem seems to be the libraries required by the Bioconductor
> package Rhtslib
> . My
> package compiles fine when using GCC 8 via Rtools 40 (and when built using
> "r-devel-windows-ix86+x86_64-gcc8" on CRAN), but when trying to submit a
> new version to CRAN, it fails its automatic tests without working using 
GCC
> 4 on Windows. Does anyone have ideas on how to fix this? Thank you!
> 
> Cheers,
> Lucas
> 
> 
> 
> * installing *source* package 'jackalope' ...
> ** using staged installation
> ** libs
> 
> *** arch - i386
> d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11
> -I"D:/RCompile/CRANpkg/lib/4.0/zlibbioc/include"
> -I"D:/RCompile/recent/R/include" -DNDEBUG -I../inst/include/
> -D_FILE_OFFSET_BITS=64 -I'D:/RCompile/CRANpkg/lib/4.0/Rcpp/include'
> -I'D:/RCompile/CRANincoming/R-devel/lib/RcppArmadillo/include'
> -I'D:/RCompile/CRANpkg/lib/4.0/RcppProgress/include'
> -I'D:/RCompile/CRANpkg/lib/4.0/Rhtslib/include'
> -I'D:/RCompile/CRANpkg/lib/4.0/zlibbioc/include'
> -I"d:/Compiler/gcc-4.9.3/local330/include" -O2 -Wall  -mtune=core2 -c
> RcppExports.cpp -o RcppExports.o
> 
> [...]
> 
> d:/Compiler/gcc-4.9.3/mingw_32/bin/g++ -shared -s -static-libgcc -o
> jackalope.dll tmp.def RcppExports.o alter_reference.o create_sequences.o
> hts_illumina.o hts_pacbio.o io_fasta.o io_ms.o io_vcf.o mutator.o
> mutator_indels.o mutator_subs.o phylogenomics.o ref_var_access.o
> sub_models.o util.o var_classes.o vars_ssites.o -lws2_32
> -LD:/RCompile/recent/R/bin/i386 -lRlapack -LD:/RCompile/recent/R/bin/i386
> -lRblas -lgfortran -lm -lquadmath
> D:/RCompile/CRANpkg/lib/4.0/Rhtslib/usrlib/i386/libhts.a
> -LC:/extsoft/lib/i386 -lcurl -lrtmp -lssl -lssh2 -lcrypto -lgdi32 -lz
> -lws2_32 -lwldap32 -lwinmm -lidn
> -LD:/RCompile/CRANpkg/lib/4.0/zlibbioc/libs/i386 -lzlib1bioc
> -Ld:/Compiler/gcc-4.9.3/local330/lib/i386
> -Ld:/Compiler/gcc-4.9.3/local330/lib -LD:/RCompile/recent/R/bin/i386 -lR
> 
D:/Compiler/gcc-4.9.3/mingw_32/bin/../lib/gcc/i686-w64-mingw32/4.9.3/../../../../i686-w64-mingw32/bin/ld.exe:
> cannot find -lcurl
> 
D:/Compiler/gcc-4.9.3/mingw_32/bin/../lib/gcc/i686-w64-mingw32/4.9.3/../../../../i686-w64-mingw32/bin/ld.exe:
> cannot find -lrtmp
> 
D:/Compiler/gcc-4.9.3/mingw_32/bin/../lib/gcc/i686-w64-mingw32/4.9.3/../../../../i686-w64-mingw32/bin/ld.exe:
> cannot find -lssl
> 
D:/Compiler/gcc-4.9.3/mingw_32/bin/../lib/gcc/i686-w64-mingw32/4.9.3/../../../../i686-w64-mingw32/bin/ld.exe:
> cannot find -lssh2
> 
D:/Compiler/gcc-4.9.3/mingw_32/bin/../lib/gcc/i686-w64-mingw32/4.9.3/../../../../i686-w64-mingw32/bin/ld.exe:
> cannot find -lcrypto
> 
D:/Compiler/gcc-4.9.3/mingw_32/bin/../lib/gcc/i686-w64-mingw32/4.9.3/../../../../i686-w64-mingw32/bin/ld.exe:
> cannot find -lidn
> collect2.exe: error: ld returned 1 exit status
> no DLL was created
> ERROR: compilation failed for package 'jackalope'
> * removing 'd:/RCompile/CRANincoming/R-devel/lib/jackalope'
> 
>   [[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-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] two functions with the same name when importing

[Martin Morgan]

RShowDoc("R-exts") setion 1.5.1 Specifying imports and exports indicates that 
imports() has an except= argument, so

import(adegenet, except = plot)

might do the trick. Use it in your package as `adegenet::plot()`. 

Martin Morgan

On 11/6/19, 8:31 PM, "R-package-devel on behalf of Duncan Murdoch" 
 
wrote:

On 06/11/2019 6:50 p.m., Bernd.Gruber wrote:
> Hi,
> 
> I have a problem regarding the name of two functions and I know the 
"correct" way is to use importFrom to make sure only specified functions are 
imported. But my problem is that my package really depends on another package
> adegenet as I basically use 90% of the say >100 functions.
> 
> So when I import all of adegenet I get:
> 
> 2: replacing previous import 'adegenet::plot' by 'graphics::plot' when 
loading 'dartR'
> 
> 
> So in essence I think adegenet is importing a plot function which 
collides with the basic plot function. Is there anything I can do, without 
going through 100 functions and using importFrom
> 
> In addition I actually need the plot function from adegenet, so I would 
need to rename it as well somehow.
> 
> Any hint how to solve this would be highly appreciated.

Just get a copy of the adegenet NAMESPACE file to get all of its 
exports.  Edit the list down to the ones you use, and use a text editor 
to change the export directives to importFrom directives.  It's not 
really that hard.

The path to the NAMESPACE file is given by

system.file("NAMESPACE", package="adegenet")

Duncan Murdoch

__
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] [External] Re: Packages required and available but unsuitable versions: Error

[Martin Morgan]

The warnings are fixed by changing the NAMESPACE file, not the DESCRIPTION 
file. Decide which function(s) you would like to import, and import only those 
using importFrom("Matrix", "sparseMatrix") or import("Matrix", except = 
"toeplitz")

Martin

On 9/23/19, 8:45 AM, "Agarwal, Divyansh" 
 wrote:

Hi Martin,

Thanks so much. Removing the version dependencies for those 3 packages 
fixed the ERROR but I'm now having an issue with these WARNINGS:
Warning: replacing previous import ‘AnnotationDbi::select’ by 
‘MASS::select’ when loading ‘multicross’
Warning: replacing previous import ‘Matrix::cov2cor’ by ‘stats::cov2cor’ 
when loading ‘multicross’
Warning: replacing previous import ‘Matrix::toeplitz’ by ‘stats::toeplitz’ 
when loading ‘multicross’
Warning: replacing previous import ‘nbpMatching::quantile’ by 
‘stats::quantile’ when loading ‘multicross’
Warning: replacing previous import ‘Matrix::update’ by ‘stats::update’ when 
loading ‘multicross’

Looking at a couple of forums I thought putting stats and MASS under 
"Depends" in the DESCRIPTION file would address these warnings, but they still 
come up. For reference, my DESCRIPTION file is –

Depends:
  stats (>= 3.5.0),
  MASS (>= 7.3-49),
Encoding: UTF-8
 Imports:
  nbpMatching (>= 1.5.1),
  crossmatch (>= 1.3-1),
  Matrix (>= 1.2-17),
  org.Hs.eg.db (>= 3.6.0),
  org.Mm.eg.db (>= 3.6.0),
  org.Ce.eg.db (>= 3.6.0),
  Seurat (>= 3.0.0),
  AnnotationDbi (>= 1.42.1)

Please let me know what you'd recommend. Thank you again for taking the 
time to offer your help, and am really grateful for your suggestions. 

Sincerely,
Divyansh


On 9/23/19, 7:44 AM, "Martin Morgan"  wrote:

Probably the easiest 'solution' is to remove the version dependencies, 
e.g., 'org.Hs.eg.db, org.Mm.eg.db, ...'.

I suspect that the root cause is that the Windows builders do not have 
the correct version of these packages installed for the version of R in use, 
perhaps because the version of the package BiocVersion (it should be 3.10.1 in 
R-devel) is incorrect.

Martin Morgan
Bioconductor

On 9/23/19, 6:06 AM, "R-package-devel on behalf of Agarwal, Divyansh" 
 wrote:

Dear R developers community,

I’m trying to build and submit an R package to CRAN but keep 
getting the following error:
Packages required and available but unsuitable versions:
  'org.Hs.eg.db', 'org.Mm.eg.db', 'org.Ce.eg.db'

The DESCRIPTION file for my package includes the following:
Depends:
  R (>= 3.5.0),
  stats (>= 3.5.0),
  MASS (>= 7.3-49),
Encoding: UTF-8
Imports:
  nbpMatching (>= 1.5.1),
  crossmatch (>= 1.3-1),
  Matrix (>= 1.2-17),
  org.Hs.eg.db (>= 3.6.0),
  org.Mm.eg.db (>= 3.6.0),
  org.Ce.eg.db (>= 3.6.0),
  Seurat (>= 3.0.0),
  AnnotationDbi (>= 1.42.1)

The details of the error log are here: 
<https://win-builder.r-project.org/incoming_pretest/multicross_2.0.0_20190923_044655/>

I’ve tried a few different things such as specifying an R version 
under “Depends” or updating the version for the “org.” packages to the latest 
version (>=3.8) but I haven’t been able to resolve the error and warnings shown 
in the error log.  I would be really grateful to you if you could kindly advise 
a potential solution for how to possibly fix this error.

Thanks a lot in advance!
Divyansh



[[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] Packages required and available but unsuitable versions: Error

[Martin Morgan]

Probably the easiest 'solution' is to remove the version dependencies, e.g., 
'org.Hs.eg.db, org.Mm.eg.db, ...'.

I suspect that the root cause is that the Windows builders do not have the 
correct version of these packages installed for the version of R in use, 
perhaps because the version of the package BiocVersion (it should be 3.10.1 in 
R-devel) is incorrect.

Martin Morgan
Bioconductor

On 9/23/19, 6:06 AM, "R-package-devel on behalf of Agarwal, Divyansh" 
 wrote:

Dear R developers community,

I’m trying to build and submit an R package to CRAN but keep getting the 
following error:
Packages required and available but unsuitable versions:
  'org.Hs.eg.db', 'org.Mm.eg.db', 'org.Ce.eg.db'

The DESCRIPTION file for my package includes the following:
Depends:
  R (>= 3.5.0),
  stats (>= 3.5.0),
  MASS (>= 7.3-49),
Encoding: UTF-8
Imports:
  nbpMatching (>= 1.5.1),
  crossmatch (>= 1.3-1),
  Matrix (>= 1.2-17),
  org.Hs.eg.db (>= 3.6.0),
  org.Mm.eg.db (>= 3.6.0),
  org.Ce.eg.db (>= 3.6.0),
  Seurat (>= 3.0.0),
  AnnotationDbi (>= 1.42.1)

The details of the error log are here: 
<https://win-builder.r-project.org/incoming_pretest/multicross_2.0.0_20190923_044655/>

I’ve tried a few different things such as specifying an R version under 
“Depends” or updating the version for the “org.” packages to the latest version 
(>=3.8) but I haven’t been able to resolve the error and warnings shown in the 
error log.  I would be really grateful to you if you could kindly advise a 
potential solution for how to possibly fix this error.

Thanks a lot in advance!
Divyansh



[[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] Link compiled C object to internal package file

[Martin Morgan]

Section 1.2 of 'Writing R Extensions' says

Another example is when a package installs support files that are required at 
run time, and their location is substituted into an R data structure at 
installation time. The names of the top-level library directory (i.e., 
specifiable via the ‘-l’ argument) and the directory of the package itself are 
made available to the installation scripts via the two shell/environment 
variables R_LIBRARY_DIR and R_PACKAGE_DIR. Additionally, the name of the 
package (e.g. ‘survival’ or ‘MASS’) being installed is available from the 
environment variable R_PACKAGE_NAME. (Currently the value of R_PACKAGE_DIR is 
always ${R_LIBRARY_DIR}/${R_PACKAGE_NAME}, but this used not to be the case 
when versioned installs were allowed. Its main use is in configure.win scripts 
for the installation path of external software’s DLLs.) Note that the value of 
R_PACKAGE_DIR may contain spaces and other shell-unfriendly characters, and so 
should be quoted in makefiles and configure scripts

which sounds approximately similar to your situation and suggests using the 
full path to the installed file R_PACKAGE_DIR/dict/.

It's not really clear what your two use cases are below, specifically the 
unique circumstances of 'in tests only'. I would guess that a relative path 
would not work, in general, because the path would be relative to the current 
working directory, which of course changes, rather than relative to the path of 
the shared object...

Martin Morgan

On 6/19/19, 10:46 AM, "R-package-devel on behalf of mark padgham" 
 
wrote:

Yeah, but that would require completely rewriting the C code to accept a
variable for something that is used hundreds of times as a simple macro.
(Most of that C code is an old library bundled with the package, so not
my work in that regard.) It would still be enormously easier to robustly
provide a relative location within the compiled source object to direct
it to the file ... but how?


On 19/06/2019 14:10, Jeff Newmiller wrote:
> What do you mean by
>
> "call an external text file"
>
> ? Text files are data... do you want to open it and read it? Are you 
familiar with the system.file() function?
>
>
> On June 19, 2019 5:45:51 AM CDT, mark padgham  
wrote:
>> Dear All,
>>
>> I'm developing a package which primarily relies on C code that itself
>> has to call an external text file representing a dictionary or lookup
>> table. The location of this file is defined in a C macro, the file
>> itself packaged in "./inst/dict/" and so currently called
>> as
>> "#define mylocation './dict/'". I can load the package and
>> all works well, yet the tests fail because the compiled object
>> ("./src/") can not find this file **in tests only**. My
>> primary request would then be advice for where best to place such files
>> that need to be called directly by compiled objects, and how to direct
>> the compiled object to such files? Failing that, advice on why such
>> attempts at linking compiled objects to external files might fail only
>> during tests, yet work otherwise, would be appreciated.
>>
>> Other important info: Yes, the external dictionary file **must** be
>> linked directly from the compiled object, not at run time. This means
>> that no R-based solutions can be implemented, and so the problem can
>> only be solved in this case through figuring out how to direct a
>> compiled object to connect to an additional package-internal file.
>>
>> Thanks in advance,
>>
>> mark
>>
>> __
>> 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-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Advice on setAs - issue of "in method for 'coerce' with signature / no definition for classes

[Martin Morgan]

Since ncdf4 (and emld) both use S3 class systems, it is sufficient to simply 
declare

setOldClass("ncdf4")

some time prior to using setAs() .

Martin

On 5/24/19, 6:41 PM, "R-package-devel on behalf of Emmanuel Blondel (GMAIL)" 
 wrote:

Dear all, I write here as i'm in process to submit a revision of 
/geometa/ package to CRAN in which i've enabled some coercing methods 
between main metadata object ISOMetadata from geometa, and foreign 
metadata objects (from emld / ncdf4 packages)

I've received a "pre-test archived" notification, because of the 
folllowing warnings dealing with the coercing:

   Warning: in method for 'coerce' with signature '"ISOMetadata","emld"': 
no definition for classes "ISOMetadata", "emld"
   Warning: in method for 'coerce' with signature '"emld","ISOMetadata"': 
no definition for classes "emld", "ISOMetadata"
   Warning: in method for 'coerce' with signature '"ncdf4","ISOMetadata"': 
no definition for classes "ncdf4", "ISOMetadata"

Detail at: 

https://win-builder.r-project.org/incoming_pretest/geometa_0.5-0_20190524_153346/Windows/00check.log

I've found this thread that seems to discuss the same matter: 
https://github.com/r-spatial/sf/issues/129 . I'm facing the same 
situation where there is no good reason enough to add emld, ncdf4 as 
Imports, but rather to keep them as Suggests, as they are only used in 
these specific converters. In the doubt, i prefer asking here if there 
is some good practice to deal with these warnings, eventually to avoid 
it, or if this is considered by CRAN team as false positive.

Thanks a lot for your advice,

Best,
Emmanuel



[[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] CRAN student assistants

[Martin Morgan]

message() / warning() / stop() write to stderr whereas print() / cat() write 
(by default) to stdout. Even without being able to suppress messages, it is 
well-established practice (the story is that this is the reason why 'stderr' 
was introduced into unix, 
https://www.jstorimer.com/blogs/workingwithcode/7766119-when-to-use-stderr-instead-of-stdout
 ) to separate diagnostic messages from program output. I agree that gargle (in 
particular, and packages in general, given the theme of this mailing list) 
would be a better package if it used message() where it now uses cat().

Martin

On 5/15/19, 5:04 AM, "R-package-devel on behalf of Joris Meys" 
 wrote:

2) Where cat() is used in gargle, message() is a better option for the
following reason:

> myfun <- function(){cat("Yes");message("No")}
> suppressMessages(myfun())
Yes


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

Re: [R-pkg-devel] Help with the warning : 'BiocInstaller' and 'biocLite()' are deprecated, use the 'BiocManager' CRAN

[Martin Morgan]

From Bioconductor's perspective, this warning is safe to ignore. But only CRAN 
knows whether they do or not.

Note the unusual situation that the check is on the 'devel' branch of R, but 
that the package that signals the warning comes from the branch of Bioconductor 
meant for R-3.5.* -- CRAN apparently uses 3.5.* package binaries (for both CRAN 
& Bioconductor) in R-devel.

Martin Morgan

On 3/6/19, 10:00 AM, "R-package-devel on behalf of Yonghui Dong" 
 
wrote:

Dear all,

I remember somebody has asked a similar question days ago, but the problem 
has not been solved. I am sorry that I ask this question again.

My package can pass the CMD check in my local PC, while when I submit my 
package to CRAN, there is one warning:

>Found the following significant warnings:
Warning: 'BiocInstaller' and 'biocLite()' are deprecated, use the 
'BiocManager' CRAN

One of my R package dependencies is a bioconductor package xcms. It seems 
that packages from Bioconducor cannot be installed now.

More details are given in the directory:


https://win-builder.r-project.org/incoming_pretest/Miso_0.2.1_20190304_095427/Windows/
 
<https://win-builder.r-project.org/incoming_pretest/Miso_0.2.1_20190304_095427/Windows/>

Thanks a lot for your help.

Dong
[[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] Bioconductor dependencies => Windows checks failed

[Martin Morgan]

Bioconductor 3.8 is the current release version of Bioconductor, and should be 
used by CRAN for current release versions of R. This seems perhaps like a stale 
installation on the Windows machine.

A link to the actual check report would be helpful.

Martin

On 2/27/19, 9:25 AM, "R-package-devel on behalf of Matthew Hall" 
 
wrote:

Hello,

I’ve just tried to submit a package to CRAN which has a Bioconductor 
dependency (ggtree, specifically). It passes checks on MacOS and Debian, but 
fails on Windows with the error:

Error: object 'as_data_frame' is not exported by 'namespace:tidytree'

The official ggtree developer solution to this known issue is to upgrade to 
Bioconductor 3.8, so I’m guessing the version used in the check is earlier? Is 
there anything I can do?

Thanks, Matthew

[[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] Regarding maGUI package error

[Martin Morgan]

On Windows, likely the warning about BiocInstaller comes from a package 
dependency, rather than your package.

Somehow this seems like a CRAN misconfiguration or perhaps workaround to 
accommodate packages that need to be fixed. The warning message comes when 
loading BiocInstaller (BiocInstaller has been replaced by BiocManager, which is 
a standard CRAN package). The development version of R should be using the 
development version of Bioconductor. BiocInstaller was removed from the 
development version of Bioconductor, so the warning message should not appear 
-- any package trying to load BiocInstaller should simply fail.

Martin Morgan

On 2/20/19, 2:06 AM, "R-package-devel on behalf of dhamma pal" 
 
wrote:

Hi.
Following is the check results from CRAN server, though I didn't get any
warning on my PC.

package maGUI_2.3.tar.gz does not pass the incoming checks automatically,
please see the following pre-tests:
Windows: <

https://win-builder.r-project.org/incoming_pretest/maGUI_2.3_20190217_181340/Windows/00check.log
>
Status: 1 WARNING, 1 NOTE
Debian: <

https://win-builder.r-project.org/incoming_pretest/maGUI_2.3_20190217_181340/Debian/00check.log
>
Status: 1 NOTE

Last released version's CRAN status: ERROR: 2
See: <https://CRAN.R-project.org/web/checks/check_results_maGUI.html
<https://cran.r-project.org/web/checks/check_results_maGUI.html>>

CRAN Web: <https://cran.r-project.org/package=maGUI>

Please fix all problems and resubmit a fixed version via the webform.
If you are not sure how to fix the problems shown, please ask for help on
the R-package-devel mailing list:
<https://stat.ethz.ch/mailman/listinfo/r-package-devel>
If you are fairly certain the rejection is a false positive, please
reply-all to this message and explain.

More details are given in the directory:
<

https://win-builder.r-project.org/incoming_pretest/maGUI_2.3_20190217_181340/
>
The files will be removed after roughly 7 days.

No strong reverse dependencies to be checked.

Best regards,
CRAN teams' auto-check service
Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
Check: CRAN incoming feasibility, Result: NOTE
  Maintainer: 'Dhammapal Bharne '

  New submission

  Package was archived on CRAN

  CRAN repository db overrides:
X-CRAN-Comment: Archived on 2018-11-01 as check warnings were not
  corrected despite a month's notice.

Needed change for BioC 3.8

Flavor: r-devel-windows-ix86+x86_64
Check: whether package can be installed, Result: WARNING
  Found the following significant warnings:
Warning: 'BiocInstaller' and 'biocLite()' are deprecated, use the
'BiocManager' CRAN
  See 'd:/RCompile/CRANincoming/R-devel/maGUI.Rcheck/00install.out' for
details.

Flavor: r-devel-windows-ix86+x86_64
Check: Overall checktime, Result: NOTE
  Overall checktime 11 min > 10 min


On Wed, 20 Feb 2019, 2:36 am Duncan Murdoch  On 19/02/2019 11:47 a.m., dhamma pal wrote:
> > Dear all.
> > The current version of the maGUI package is 2.2 which got errors after
> the
> > upgradation of R version.
> >
> > Therefore I was trying to submit new version 2.3 of the package but
> getting
> > warnings of the previous version of 2.2 at the CRAN incoming Precheck
> > server.
> >
> > To resolve this, Do I need to upload the corrected package with the 2.2
> > version?
> > or How to rectify the errors of the previous version the packages at the
> > CRAN repository?
> >
> > Note: The error message is that "BiocInstaller and biocLite packages are
> > depreciated. Use BiocManager instead." Therefore I have replaced these
> > packages with BiocManager package. But now It couldn't upload at CRAN
> > because of the errors in the previous version.
>
> I suspect your interpretation of the messages you've received could be
> incorrect.  Could you post a copy of it if it came by email, or a link
> if it's on a web page?
>
> One reason you may have trouble uploading a revision is that you were
> unresponsive to requests for fixes in the previous one, and your package
> has been archived:  see
>
> https://cran.r-project.org/web/packages/maGUI/index.html
>
> and
>
>
> 
https://cran-archive.r-project.org/web/checks/2018-11-01_check_results_maGUI.html
>
> The stuff about the Bioconductor packages is shown as warnings, but you
> also have errors.  Did you fix everything?
>
>

Re: [R-pkg-devel] Use of assignInNamespace in package

[Martin Morgan]

The obvious solution is to contact the maintainer of the package generating the 
spurious warning and have it addressed 'at source'.

Probably it helps to be specific about the package generating the warning, the 
nature of the warning, and a link to your package.

I would view assignInNamespace as very poor practice -- it changes the behavior 
of the package conditional on whether your package is in use or not in a way 
that will be mysterious to most users.

Rather than using sink, one could use 'calling handlers' together with pattern 
matching

withCallingHandlers({
warning("foo")
warning("bar")
1
}, warning = function(w) {
if (identical(conditionMessage(w), "foo"))
invokeRestart("muffleWarning")
})

but a significant challenge is that the text of warnings, especially from base 
functions, may be translated into other languages so pattern matching is not 
robust. In one's own code one could signal and handle specific classes of 
objects

withCallingHandlers({
cond <- simpleWarning("foo")
class(cond) <- c("my_warning", class(cond))
warning(cond)
warning("bar")
}, my_warning = function(...) invokeRestart("muffleWarning"))

Martin Morgan

On 2/7/19, 5:33 AM, "R-package-devel on behalf of Ege Rubak" 
 wrote:

This in not well thought through, but what about using `sink` to capture 
any messages from the call? Then you might be able to remove the 
expected warning and output any remaining warnings if they are there...

However, note this part of `help(sink)`:

Sink-ing the messages stream should be done only with great care. For 
that stream file must be an already open connection, and there is no 
stack of connections.

Probably some of the real experts on the list can give you better advice :-)

f <- tempfile(fileext = ".Rout")
zz <- file(f, open = "wt")
sink(zz, type = "message")
warning("Expeced warning.")
warning("Another warning.")
sink(type = "message")
mesg <- readLines(f)
mesg

/Ege

On 07/02/2019 10.58, Hugh Parsonage wrote:
> Hello,
> 
> I'm considering a package submission. I have used assignInNamespace,
> which is hideous but seems better than the alternatives. I see that it
> returns a NOTE on R CMD check, suggesting that it is not absolutely
> prohibited, but would require justification.
> 
> The justification I would make is that it fixes a spurious warning
> emitted by the namespace and that the assignInNamespace call would
> require user intervention or the presence of an (unset) package option
> or environment variable before being run. The alternatives would be to
> use `suppressWarnings` (but this risks suppressing other, valid
> warnings), to fork the package and submit the patched version as a
> standalone package to CRAN first (which seems excessive or without
> merit given the patch would be just one line), or to write a message
> on package startup with the intended `assignInNamespace` call,
> together with a recommendation to copy and run it before continuing
> (which seems worse than assigning it within the package, considering
> the message may be copied wrongly, and would have to be done on every
> load).
> 
> I note the CRAN policy on 'malicious or anti-social' behaviour. My
> read of 'Limited exceptions may be allowed in interactive sessions if
> the package obtains confirmation from the user.' is that the usage
> I've described may be allowed.  Agreement with the namespace owner
> seems to offer another justification, though I haven't heard back from
> the maintainer. (The patch is fairly inconsequential so the lack of
> response is understandable.)
> 
> I also note the Warning in ?getFromNamespace regarding this function,
> but as I said, it seems the least worst option.
> 
> 
> Best,
> 
> Hugh.
> 
> __
> 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-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] define an environment in .onLoad

[Martin Morgan]

A variant (not quite as good because parent = emptyenv() is not an argument) is

pkg_data <- local({ a = 1; b =2; environment() })

If information at load time is also important, one might add

.onLoad <- function(libname, pkgname) {
pkg_data[["last_update"]] <- Sys.time()
}

which is actually a fun test of one's understanding of R's assignment and 
symbol look-up rules.

Martin Morgan

On 1/29/19, 4:50 PM, "R-package-devel on behalf of Gábor Csárdi" 
 
wrote:

You don't need .onLoad for this, just put the environment into the
package environment. E.g. simply add

pkg_data <- new.env(parent = emptyenv())

to your package code. Then you can refer to pkg_data from the
functions in the package.

Best,
Gabor

On Tue, Jan 29, 2019 at 9:40 PM Pascal Title  wrote:
>
> Hi,
>
> I am developing an R package where I would like to have a set of names
> defined once, and which could then be queried from within the various
> functions of the package. The way I have currently set this up is to 
define
> a new environment that contains these names.
>
> So, what I currently have is:
>
> .var <- new.env()
>
> .var$bio <- "bio_"
>
> .var$tmin <- "tmin_"
>
> .var$tmax <- "tmax_"
>
> What I would like is that this environment be created when the R package 
is
> loaded. That way, default values are automatically in place, and if the
> user would like to change the naming that they use for tmin, for example,
> they would just need to do (for example):
>
>
> .var$tmin <- ‘minTemp_'
>
>
> And then these names can be accessed from within any of the functions, and
> this is unlikely to conflict with any R objects the user is defining.
>
>
> Where I am stuck is how/where to define this new environment such that it
> is made available when the package is loaded. I tried including the
> following in R/zzz.R:
>
>
> .onLoad <- function(libname, pkgname) {
>
>
>   # define a custom environment for defining the naming of variables
>
> .var <- new.env()
>
> # default
>
> .var$bio <- "bio_"
>
> .var$tmin <- "tmin_"
>
> .var$tmax <- "tmax_"
>
> invisible()
>
> }
>
>
> But if I build/install the package, the .var environment is not already
> created. Any suggestions?
>
>
> Thanks!
>
> -Pascal
>
> [[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-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] About a need for hooks from R CMD ... commands, and a question

[Martin Morgan]

Add a tag to the DESCRIPTION file or configure.ac-like indicating the git 
(presumably) revision, perhaps like https://stackoverflow.com/a/11535358/547331 
?

On 1/4/19, 1:42 PM, "R-package-devel on behalf of Dirk Eddelbuettel" 
 wrote:


On 4 January 2019 at 19:24, Iñaki Ucar wrote:
| On Fri, 4 Jan 2019 at 16:43, Dirk Eddelbuettel  wrote:
| >
| >
| > For a few years now I had mused about how nice it would be to have other
| > scripts triggered like `cleanup`.  For Rcpp, it would be nice to run
| > compileAttributes(). For roxygen2, it would be nice to run roxygenize()
| > (especially if that continued to work the way it did, but I digress).
| > That was mostly a "wouldn't it be nice" question and not that urgent as 
I
| > wrote myself littler scripts for most tasks anyway.
| >
| > But I now have a related problem at work. We are authoring C++ 
libraries and
| > R packages 'mono-repo' style. And I need to reference builds of the R
| > packages back to the repo branches / repo directories used where R CMD 
build
| > ran in a branch -- in order to at R CMD INSTALL time access the matching
| > header files and libraries from that branch.  I do not see an obvious 
way of
| > encoding this in the .tar.gz created by the R CMD build step. The best 
I can
| > think of is creating binaries via R CMD INSTALL --build instead of 
creating
| > source tarballs.
| >
| > Is there something better I am missing? Any hacks, hints, or ideas?
| 
| I'm not sure whether I understand correctly what you are trying to
| achieve. Isn't generating a custom configure script enough for your
| needs?

That is what I thought yesterday when I wrote / updated and tested those.
They work great when you install from source as they have access to shell's
${PWD} and R's getwd().

But when you run R CMD build, (essentially) just cleanup and a tar are
running. No other code. Hence my Subject: here -- a need for a hook.

Once you have built a .tar.gz and run R CMD INSTALL on it, R goes off to
_another temporary directory_ and while configure may be running ... you are
no longer in the directory you called it from. So I have now lost the
connection to the particular variant of headers and libraries I may have had
in that branch.

Doing R CMD INSTALL --build ... is a workaround.  But it still would be nice
to have an explicit hook.

Hope this explains it better, and thanks for the follow-up.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

__
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] Fwd: [CRAN-pretest-archived] CRAN submission maGUI 2.3

[Martin Morgan]

I cannot tell whether this will be helpful or not. It looks to me like the 
warning occurs when one of your dependencies uses BiocInstaller. You could 
create a database of all available packages

  chooseCRANmirror()
  chooseBioCmirror()
  db = available.packages()

find the installation dependencies of your package dependencies

  flds = c("Depends", "Imports", "LinkingTo")
  pkgs = read.dcf("DESCRIPTION", flds)[, flds]
  pkgs = trimws(unlist(strsplit(pkgs, ","), use.names = FALSE))
  pkgs = pkgs[!is.na(pkgs)]

and discover which references BiocInstaller

  deps = tools::package_dependencies(pkgs, db, recursive = TRUE)
  unlist(deps)["BiocInstaller" %in% unlist(deps)]

But actually when I run this with version 2.2 of your package I don't see a 
dependency on BiocInstaller (other than in your own package).

Martin

On 11/11/18, 9:55 PM, "R-package-devel on behalf of dhamma pal" 
 
wrote:

The latest version donot use BIOCINSTALLER or bioclite, still getting a
warning.

Errors are not detected in the current version, i.e. 2.3 version of maGUI.
But errors are getting reported in the earlier version i.e., 2.2 which is
not the making the current version to pass through the CRAN. I have tried
to submit the corrected  package with version 2.2 to rectify the errors,
but getting overriden error. Now how to ugrade maGUI to 2.3?
Thanks in advance.


-- Forwarded message -
From: 
Date: Thu, 8 Nov 2018, 1:12 pm
Subject: [CRAN-pretest-archived] CRAN submission maGUI 2.3
To: 
Cc: 


Dear maintainer,

package maGUI_2.3.tar.gz does not pass the incoming checks automatically,
please see the following pre-tests:
Windows: <

https://win-builder.r-project.org/incoming_pretest/maGUI_2.3_20181108_081501/Windows/00check.log
>
Status: 1 WARNING, 1 NOTE
Debian: <

https://win-builder.r-project.org/incoming_pretest/maGUI_2.3_20181108_081501/Debian/00check.log
>
Status: 1 NOTE

Last released version's CRAN status: ERROR: 2
See: 

CRAN Web: 

Please fix all problems and resubmit a fixed version via the webform.
If you are not sure how to fix the problems shown, please ask for help on
the R-package-devel mailing list:

If you are fairly certain the rejection is a false positive, please
reply-all to this message and explain.

More details are given in the directory:
<

https://win-builder.r-project.org/incoming_pretest/maGUI_2.3_20181108_081501/
>
The files will be removed after roughly 7 days.

No strong reverse dependencies to be checked.

Best regards,
CRAN teams' auto-check service
Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
Check: CRAN incoming feasibility, Result: NOTE
  Maintainer: 'Dhammapal Bharne '

  New submission

  Package was archived on CRAN

  CRAN repository db overrides:
X-CRAN-Comment: Archived on 2018-11-01 as check warnings were not
  corrected despite a month's notice.

Needed change for BioC 3.8

Flavor: r-devel-windows-ix86+x86_64
Check: whether package can be installed, Result: WARNING
  Found the following significant warnings:
Warning: 'BiocInstaller' and 'biocLite()' are deprecated, use the
'BiocManager' CRAN
  See 'd:/RCompile/CRANincoming/R-devel/maGUI.Rcheck/00install.out' for
details.

[[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] Puzzled about "locked environments".

[Martin Morgan]

On 07/08/2018 07:23 PM, Duncan Murdoch wrote:

On 08/07/2018 6:57 PM, Rolf Turner wrote:


Recently I experimented with assigning a variable within the environment
of a function in a package that I am developing.  Slightly more 
explicitly:


In a function "foo()" in the package, I have lines like:

 big <- 42
 assign("big",big,envir=environment(bar))

where "bar()" is another function in the package.

This causes an error to be thrown:


Error in assign("big", big, envir = environment(bar)) :
   cannot add bindings to a locked environment


The reason that I am puzzled about this is that I used this syntax
repeatedly in my CRAN package "AssetPricing".  In this latter package
the syntax seems to work flawlessly.  No errors are thrown.  No mention
of "locked environments".

Why would environments get "locked" in the package that I am currently
fooling about with, but not in the AssetPricing package?  Is there
anything that I  can do to keep environments from getting "locked"?


It may be the timing.  When R is installing a package, it executes all 
of the code in the .R files (which has been consolidated into one file, 
but that doesn't matter).  This produces all of the objects and 
functions in the package.


Then it locks the environment, so that things don't change.

Then it compiles the functions.  If they were allowed to change, then 
the compilation would have to be redone.


So perhaps AssetPricing makes the change in the .R file, processed 
before locking, and your new package does it in a function, executed by 
the user after locking.


AssetPricing does, at least some of the time, in the body of a function 
(the indentation is confusing)


environment(vupdate) <- new.env()
environment(scrG) <- new.env()
environment(initx) <- new.env()
environment(cev) <- new.env()

#
assign("dS",dS,envir=environment(vupdate))
assign("dS",dS,envir=environment(scrG))
assign("dS",dS,envir=environment(initx))
assign("dS",dS,envir=environment(cev))

so that assignment is to the unlocked new.env(). Presumably the new code 
assigns to bar's original environment, which is the (locked, once the 
package is loaded) package name space.


Martin Morgan



Or maybe not.

Duncan Murdoch



Can anyone suggest where I should start looking for differences in the
nature of the two packages?

I could possibly give more detail, but I have no idea as to what might
be relevant.

One difference is that AssetPricing involves no dynamically loaded
Fortran code, whereas the package that I am currently fooling about with
*does* involve such code.  (But neither "foo()" not "bar()" make direct
calls to .Fortran().)

Grateful for any insights.

cheers,

Rolf Turner



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



This email message may contain legally privileged and/or...{{dropped:2}}

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

Re: [R-pkg-devel] why can't we importFrom 'methods' ?

[Martin Morgan]

On 05/17/2018 11:59 AM, Duncan Murdoch wrote:

On 17/05/2018 11:51 AM, Brian G. Peterson wrote:

newer versions of R require importFrom for functions from 'stats',
'graphics' and many other packages that used to be assumed to be on the
search path and thus available.

'methods' continues to have seemingly different treatment.

If you try to use importFrom to import a single function (in this case
'hasArg') from methods, you receive an ERROR from R CMD check

 Namespace dependency not required : 'methods'


That message usually means that you didn't list 'methods' in the Imports 
clause in DESCRIPTION.


Is there a better way of formulating the message?

  Packages used in the NAMESPACE file must also be in the Imports: or 
Depends: field of the DESCRIPTION file; missing packages : 'methods'


  Package(s) not present in Imports: or Depends: of DESCRIPTION :
  'methods'

   ... ?

Martin Morgan



Duncan Murdoch



but without the importFrom, you see a number of NOTE's

 no visible global function definition for 'hasArg'

I don't want to import all of 'methods', as I only need one function.

What am I doing wrong?

Regards,

Brian



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



This email message may contain legally privileged and/or...{{dropped:2}}

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

Re: [R-pkg-devel] Rd files: using \link[pkg]{foo} when file names differ between OSs

[Martin Morgan]

On 04/16/2018 12:31 PM, Duncan Murdoch wrote:

On 16/04/2018 12:06 PM, Martin Maechler wrote:

Duncan Murdoch 
 on Mon, 16 Apr 2018 11:52:10 -0400 writes:


 > On 16/04/2018 11:35 AM, Ramon Diaz-Uriarte wrote:
 >> Dear All,
 >>
 >> Two recent threads in the bioconductor devel mailing list
 >> (https://stat.ethz.ch/pipermail/bioc-devel/2018-April/013156.html
 >> and
 >> https://stat.ethz.ch/pipermail/bioc-devel/2018-April/013259.html)
 >> are related to packages that have different names of html
 >> files in different operating systems.
 >>
 >> For example, parallel has a file called mclapply in
 >> Linux. So using, from the Rd file of another package,
 >> \link[parallel]{mclapply} works fine under Linux, but
 >> does not under Windows, because there is no mclapply.html
 >> file in Windows (there is a mcdummies file).
 >>
 >>
 >> Is there any recommended way to proceed in these cases?
 >>
 >>
 >> Yes, section 2.5 of Writing R Extensions indicates that
 >> \link[pkg]{foo} and \link[pkg:bar]{foo} are rarely
 >> needed; so the simplest way to proceed would be to avoid
 >> \link[pkg]{foo} and \link[pkg:bar]{foo}. I am asking for
 >> the cases where, as noted in 2.5, "more than one package
 >> offers help on a topic".

 > You could make the links conditional on the OS.  For example,

 > #ifdef windows
 > See \link[parallel]{mcdummies}.
 > #endif
 > #ifdef unix
 > See \link[parallel]{mclapply}.
 > #endif

 > The other possibility (useful if there are major differences 
between the
 > platforms) is to have two copies of the help file, one in 
man/unix, one
 > in man/windows, but that doesn't seem appropriate from your 
description.


 > Duncan Murdoch

and mid-term, I really think R and (CRAN, Bioc, ...) packages
should not do what we (R core) did here.
Rather,  \alias{mclapply}  should exist both for windows and
non-windows, and hence \link{mclapply}  would just work.


\alias{mclapply} does exist...



I forget whether that would work here:  parallel being a base package 
(used by the package in question?) might mean it would be found without 
the [parallel] in the link.  But in general, links to other packages 
using [pkg] go to the *filename*, not to the alias.  This oddity happens 
because we want the links to work even if the referenced package is 
installed later than the Rd file is processed.


People are quite concerned about fixing the 'WARNING' this generates. 
However from the text


  file link 'mclapply' in package 'parallel' does not exist and so has 
been  treated as a topic


the help pages are actually constructed correctly, finding the page on 
which the topic (aka alias) 'mclapply' is defined. This contrasts with a 
completely incorrect link (e.g., \link[stats]{mclapply}) generating a 
warning


  missing file link

and unable to link to the mclapply topic.

Perhaps the WARNING from \link[parallel]{mclapply} should be a NOTE?

There are other oddities in the threads that Ramon indicates

  - WARNINGs from \link[foo]{bar} that should really be 
\link[foo:baz]{bar} often only appear on Windows (parallel's use of 
mcdummies is a special case here). Shouldn't they be 
platform-independent? An example is



http://bioconductor.org/checkResults/3.7/bioc-LATEST/ADaCGH2/tokay2-checksrc.html

where as.MAList is defined in a file called asmalist.Rd so 
\link[limma]{as.MAList} is incorrect. It generates a warning only on our 
Windows machine (tokay2) not Linux or Mac. I had some recollection of 
Windows-specific help system behavior, but I think this dates back to 
the .chm days...


  - There were a spate of independent posts about this, suggesting that 
this is relatively new phenomenon (though it could also be that 
maintainers have been busy preparing their packages for the next 
release, so are now noticing the problem...)


  - It doesn't seem like good practice to link to the file name, which 
seems an internal aspect of a package, rather than to the alias, which 
seems at least for symbols to be a user-facing public aspect of the package.


  - And finally I did make an svn commit related to this, so am 
sensitive to blundering here


R-devel/src/library/tools/R$ svn log -c74129

r74129 | morgan | 2018-01-17 16:52:53 -0500 (Wed, 17 Jan 2018) | 10 lines

correct warning when \link[base]{foo} is incorrect

- now "missing file link" rather than "file link 'foo' in package 'base'
  does not exist and will be treated as a topic" (foo is _not_ a topic
  in base; the link to foo.html is missing)
- vice-versa for \link[base]{rbind} (rbind _is_ a topic in base, 
documented in

  cbind.html, and will be resolved by the help system)
- see https://stat.ethz.ch/pipermail/r-devel/2009-October/055287.html and
  c50198