Re: [R-pkg-devel] [External] Removing import(methods) stops exporting S4 "meta name"

[Richard M. Heiberger]

this looks like a relative of the issue I tripped on that is discussed in the 
email threads

https://stat.ethz.ch/pipermail/r-package-devel/2024q1/010531.html

https://stat.ethz.ch/pipermail/r-devel/2024-March/083259.html

At issue is the default export of
exportPattern(".") 

System generated names, which is what ".__xxx__" looks like, seem to be the 
issue.
I can't make any specific recommendations behind connecting this current issue 
to my recent experience.

Rich


> On Mar 14, 2024, at 14:34, Michael Chirico  wrote:
> 
> importFrom(data.table,`.__T__[:base`)

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

Re: [R-pkg-devel] Removing import(methods) stops exporting S4 "meta name"

[Duncan Murdoch]

To save others a bit of time, the package in question is "do", and 
Michael has already posted an issue on their Github page asking why they 
made this import:  https://github.com/yikeshu0611/do/issues/1 .


And if you remove that import and run R CMD check on "do", it fails with 
this error:


* checking examples ... ERROR
Running examples in ‘do-Ex.R’ failed
The error most likely occurred in:

> ### Name: join
> ### Title: Join two dataframes together
> ### Aliases: join join_inner join_full join_left join_right join_out
>
> ### ** Examples
>
> df1=data.frame(x=rep(c('b','a','c'),each=3),
+   y=c(1,3,6),
+   v=1:9)
>
> df2=data.frame(x=c('c','b','e'),
+v=8:6,
+foo=c(4,2,1))
> join_inner(df1,df2,'x')
Error in xj[i] : invalid subscript type 'list'
Calls: join_inner -> data.frame -> [ -> [.data.table -> [.data.frame
Execution halted

I'm pretty sure that import should not be made, but I don't know the 
intention of this example, or what the correct fix would be.


Duncan Murdoch

On 14/03/2024 2:34 p.m., Michael Chirico wrote:

In an effort to streamline our NAMESPACE, we moved from blanket
'import(methods)' to specific importFrom(methods, ) for the
objects we specifically needed.

Doing so broke a downstream package, however, which has this directive:

importFrom(data.table,`.__T__[:base`)

That package stopped installing after the above change. I can get it
to install again by adding:

importClassesFrom(methods, "[")

to our package, but I'm not sure why this would be necessary. I'm
still left with two questions:

  1. How did we end up with ".__T__[:base" in our exports when we don't
do any S4 around '[' in the package (we do export S3 methods on it)?
  2. Is there any legitimate reason for a package to try and import
such an object? In other words, is breaking this downstream package by
not adding the 'importClassesFrom' workaround the right thing to do? I
don't see any other CRAN packages with a similar directive in its
NAMESPACE.

Michael Chirico

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


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

[R-pkg-devel] Removing import(methods) stops exporting S4 "meta name"

[Michael Chirico]

In an effort to streamline our NAMESPACE, we moved from blanket
'import(methods)' to specific importFrom(methods, ) for the
objects we specifically needed.

Doing so broke a downstream package, however, which has this directive:

importFrom(data.table,`.__T__[:base`)

That package stopped installing after the above change. I can get it
to install again by adding:

importClassesFrom(methods, "[")

to our package, but I'm not sure why this would be necessary. I'm
still left with two questions:

 1. How did we end up with ".__T__[:base" in our exports when we don't
do any S4 around '[' in the package (we do export S3 methods on it)?
 2. Is there any legitimate reason for a package to try and import
such an object? In other words, is breaking this downstream package by
not adding the 'importClassesFrom' workaround the right thing to do? I
don't see any other CRAN packages with a similar directive in its
NAMESPACE.

Michael Chirico

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

Re: [Bioc-devel] xcms error with R CMD check "checking loading without being on the library search path"

[Rainer Johannes]

Dear Mike,

thanks for the excellent explanation - and yes, I think you're right (after 
some feedback also from Vince and Herve). I did re-save the objects bundled 
within xcms with a fresh installation and am now re-running a bunch of tests 
with different containers.

thanks!
jo

Johannes Rainer, PhD

Eurac Research
Institute for Biomedicine
Via A.-Volta 21, I-39100 Bolzano, Italy

email: johannes.rai...@eurac.edu
github: jorainer
mastodon: jorai...@fosstodon.org

Mike Smith wrote:


Hi Johannes,

I think RCurl is imported via the package dependency chain of xcms -> 
SummarizedExperiment -> GenomeInfoDb -> RCurl.

It looks like Hervé removed this dependency from GenomeInfoDb recently 
(https://code.bioconductor.org/browse/GenomeInfoDb/commit/9562907f6800cf6052fff9fb2f85329ff44790b6),
 and the change is present in both RELEASE_3_18 and devel.  There was a post a 
few weeks ago about how a few heavily used CRAN packages are essentially 
abandoned (XML and RCurl) and there's been a bit of a concerted effort to move 
away from them in the core BioC packages if possible - hence why Hervé has made 
that change.

As for why R CMD check is complaining, my guess would be that you have some 
saved data in xcms that expects RCurl to be available when it is loaded - 
presumably this object was created when the dependency chain above was valid.  
Now GenomeInfoDb has been changed, RCurl doesn't get installed with xcms in a 
fresh R/Bioconductor install like your Docker container.  Then when you load 
the object via data() R complains about missing the expected RCurl package.  
That's just an educated guess, but seems plausible to me.

Best,
Mike

On Wed, 13 Mar 2024 at 10:10, Rainer Johannes 
mailto:johannes.rai...@eurac.edu>> wrote:
Dear all,

we're having some rather strange errors with R CMD check on the xcms package 
recently: it will fail with this warning (which then becomes an error):

✔  checking whether the namespace can be loaded with stated dependencies (5.9s)
✔  checking whether the namespace can be unloaded cleanly (6.1s)
W  checking loading without being on the library search path (5.3s)
   Loading required package: BiocParallel
   Loading required package: MSnbase
   Loading required package: BiocGenerics

   Attaching package: ‘BiocGenerics’

   The following objects are masked from ‘package:stats’:

   IQR, mad, sd, var, xtabs

   The following objects are masked from ‘package:base’:

   Filter, Find, Map, Position, Reduce, anyDuplicated, aperm, append,
   as.data.frame, basename, cbind, colnames, dirname, do.call,
   duplicated, eval, evalq, get, grep, grepl, intersect, is.unsorted,
   lapply, mapply, match, mget, order, paste, pmax, 
pmax.int, pmin,
   pmin.int, rank, rbind, rownames, sapply, setdiff, 
sort, table,
   tapply, union, unique, unsplit, which.max, which.min

   Loading required package: Biobase
   Welcome to Bioconductor

   Vignettes contain introductory material; view with
   'browseVignettes()'. To cite Bioconductor, see
   'citation("Biobase")', and for packages 'citation("pkgname")'.

   Loading required package: mzR
   Loading required package: Rcpp
   Loading required package: S4Vectors
   Loading required package: stats4

   Attaching package: ‘S4Vectors’

   The following object is masked from ‘package:utils’:

   findMatches

   The following objects are masked from ‘package:base’:

   I, expand.grid, unname

   Loading required package: ProtGenerics

   Attaching package: ‘ProtGenerics’

   The following object is masked from ‘package:stats’:

   smooth


   This is MSnbase version 2.28.1
 Visit https://lgatto.github.io/MSnbase/ to get started.


   Attaching package: ‘MSnbase’

   The following object is masked from ‘package:base’:

   trimws

   Loading required package: RCurl
   Error: package or namespace load failed for ‘xcms’ in 
.requirePackage(package):
unable to find required package ‘RCurl’
   In addition: Warning message:
   In library(package, lib.loc = lib.loc, character.only = TRUE, logical.return 
= TRUE,  :
 there is no package called ‘RCurl’
   Execution halted

   It looks like this package has a loading problem when not on .libPaths:
   see the messages for details.


This is rather puzzling, since we're not using, requiring or importing RCurl at 
all. Also, so far I've never seen this check "checking loading without being on 
the library search path" before.

I will try to figure out what is going on and where/which package is causing 
this problem, but would be great if someone has a solution or at least a hint.

thanks!
jo

I was running this for xcms from the RELEASE_3_18 branch using the 
bioconductor/bioconductor_docker:RELEASE_3_18. The sessionInfo (after loading 
xcms):

> sessionInfo()
R version 4.3.2 (2023-10-31)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 22.04.3 LTS

Matrix products: default
BLAS:   

Re: [Rd] Spurious warning in as.data.frame.factor()

[Ivan Krylov via R-devel]

On Thu, 14 Mar 2024 10:41:54 +0100
Martin Maechler  wrote:

> Anybody trying S7 examples and see if they work w/o producing
> wrong warnings?

It looks like this is not applicable to S7. If I overwrite
as.data.frame with a newly created S7 generic, it fails to dispatch on
existing S3 classes:

new_generic('as.data.frame', 'x')(factor(1))
# Error: Can't find method for `as.data.frame(S3)`.

But there is no need to overwrite the generic, because S7 classes
should work with existing S3 generics:

foo <- new_class('foo', parent = class_double)
method(as.data.frame, foo) <- function(x) structure(
 # this is probably not generally correct
 list(x),
 names = deparse1(substitute(x)),
 row.names = seq_len(length(x)),
 class = 'data.frame'
)
str(as.data.frame(foo(pi)))
# 'data.frame':   1 obs. of  1 variable:
#  $ x:  num 3.14

So I think that is nothing to break because S7 methods for
as.data.frame will rely on S3 for dispatch.

> > The patch passes make check-devel, but I'm not sure how to safely
> > put setGeneric('as.data.frame'); as.data.frame(factor(1:10)) in a
> > regression test.  
> 
> {What's the danger/problem?  we do have "similar" tests in both
>   src/library/methods/tests/*.R
>   tests/reg-S4.R
> 
>  -- maybe we can discuss bi-laterally  (or here, as you prefer)
> }

This might be educational for other people wanting to add a regression
test to their patch. I see that tests/reg-tests-1e.R is already running
under options(warn = 2), so if I add the following near line 750
("Deprecation of *direct* calls to as.data.frame.")...

# Should not warn for a call from a derivedDefaultMethod to the raw
# S3 method -- implementation detail of S4 dispatch
setGeneric('as.data.frame')
as.data.frame(factor(1))

...then as.data.frame will remain an S4 generic. Should the test then
rm(as.data.frame) and keep going? (Or even keep the S4 generic?) Is
there any hidden state I may be breaking for the rest of the test this
way? The test does pass like this, so this may be worrying about
nothing.

-- 
Best regards,
Ivan

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

Re: [Bioc-devel] xcms error with R CMD check "checking loading without being on the library search path"

[Mike Smith]

Hi Johannes,

I think RCurl is imported via the package dependency chain of xcms ->
SummarizedExperiment -> GenomeInfoDb -> RCurl.

It looks like Hervé removed this dependency from GenomeInfoDb recently (
https://code.bioconductor.org/browse/GenomeInfoDb/commit/9562907f6800cf6052fff9fb2f85329ff44790b6),
and the change is present in both RELEASE_3_18 and devel.  There was a post
a few weeks ago about how a few heavily used CRAN packages are essentially
abandoned (XML and RCurl) and there's been a bit of a concerted effort to
move away from them in the core BioC packages if possible - hence why Hervé
has made that change.

As for why R CMD check is complaining, my guess would be that you have some
saved data in xcms that expects RCurl to be available when it is loaded -
presumably this object was created when the dependency chain above was
valid.  Now GenomeInfoDb has been changed, RCurl doesn't get installed with
xcms in a fresh R/Bioconductor install like your Docker container.  Then
when you load the object via data() R complains about missing the expected
RCurl package.  That's just an educated guess, but seems plausible to me.

Best,
Mike

On Wed, 13 Mar 2024 at 10:10, Rainer Johannes 
wrote:

> Dear all,
>
> we're having some rather strange errors with R CMD check on the xcms
> package recently: it will fail with this warning (which then becomes an
> error):
>
> ✔  checking whether the namespace can be loaded with stated dependencies
> (5.9s)
> ✔  checking whether the namespace can be unloaded cleanly (6.1s)
> W  checking loading without being on the library search path (5.3s)
>Loading required package: BiocParallel
>Loading required package: MSnbase
>Loading required package: BiocGenerics
>
>Attaching package: ‘BiocGenerics’
>
>The following objects are masked from ‘package:stats’:
>
>IQR, mad, sd, var, xtabs
>
>The following objects are masked from ‘package:base’:
>
>Filter, Find, Map, Position, Reduce, anyDuplicated, aperm, append,
>as.data.frame, basename, cbind, colnames, dirname, do.call,
>duplicated, eval, evalq, get, grep, grepl, intersect, is.unsorted,
>lapply, mapply, match, mget, order, paste, pmax, pmax.int, pmin,
>pmin.int, rank, rbind, rownames, sapply, setdiff, sort, table,
>tapply, union, unique, unsplit, which.max, which.min
>
>Loading required package: Biobase
>Welcome to Bioconductor
>
>Vignettes contain introductory material; view with
>'browseVignettes()'. To cite Bioconductor, see
>'citation("Biobase")', and for packages 'citation("pkgname")'.
>
>Loading required package: mzR
>Loading required package: Rcpp
>Loading required package: S4Vectors
>Loading required package: stats4
>
>Attaching package: ‘S4Vectors’
>
>The following object is masked from ‘package:utils’:
>
>findMatches
>
>The following objects are masked from ‘package:base’:
>
>I, expand.grid, unname
>
>Loading required package: ProtGenerics
>
>Attaching package: ‘ProtGenerics’
>
>The following object is masked from ‘package:stats’:
>
>smooth
>
>
>This is MSnbase version 2.28.1
>  Visit https://lgatto.github.io/MSnbase/ to get started.
>
>
>Attaching package: ‘MSnbase’
>
>The following object is masked from ‘package:base’:
>
>trimws
>
>Loading required package: RCurl
>Error: package or namespace load failed for ‘xcms’ in
> .requirePackage(package):
> unable to find required package ‘RCurl’
>In addition: Warning message:
>In library(package, lib.loc = lib.loc, character.only = TRUE,
> logical.return = TRUE,  :
>  there is no package called ‘RCurl’
>Execution halted
>
>It looks like this package has a loading problem when not on .libPaths:
>see the messages for details.
>
>
> This is rather puzzling, since we're not using, requiring or importing
> RCurl at all. Also, so far I've never seen this check "checking loading
> without being on the library search path" before.
>
> I will try to figure out what is going on and where/which package is
> causing this problem, but would be great if someone has a solution or at
> least a hint.
>
> thanks!
> jo
>
> I was running this for xcms from the RELEASE_3_18 branch using the
> bioconductor/bioconductor_docker:RELEASE_3_18. The sessionInfo (after
> loading xcms):
>
> > sessionInfo()
> R version 4.3.2 (2023-10-31)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Ubuntu 22.04.3 LTS
>
> Matrix products: default
> BLAS:   /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3
> LAPACK: /usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblasp-r0.3.20.so;
> LAPACK version 3.10.0
>
> locale:
>  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
>  [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
>  [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
>  [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
>  [9] LC_ADDRESS=C   LC_TELEPHONE=C
> 

Re: [Rd] Spurious warning in as.data.frame.factor()

[Martin Maechler]

> В Tue, 12 Mar 2024 12:33:17 -0700
> Hervé Pagès  пишет:

> > The acrobatics that as.data.frame.factor() is going thru in order to 
> > recognize a direct call don't play nice if as.data.frame() is an S4 
> > generic:

> >      df <- as.data.frame(factor(11:12))
> > 
> >      suppressPackageStartupMessages(library(BiocGenerics))
> >      isGeneric("as.data.frame")
> >      # [1] TRUE
> > 
> >      df <- as.data.frame(factor(11:12))
> >      # Warning message:
> >      # In as.data.frame.factor(factor(11:12)) :
> >      #   Direct call of 'as.data.frame.factor()' is deprecated.

aargh ... yes, all that's been a hack because in the end we do
want to get rid of 12  base (hence "exported") 
as.data.frame.  methods, which will lead to *less*
acrobatics, but alas for now ...


> How about something like the following:

> Index: src/library/base/R/zzz.R
> ===
> --- src/library/base/R/zzz.R  (revision 86109)
> +++ src/library/base/R/zzz.R  (working copy)
> @@ -681,7 +681,14 @@
>  bdy <- body(as.data.frame.vector)
>  bdy <- bdy[c(1:2, seq_along(bdy)[-1L])] # taking [(1,2,2:n)] to insert 
> at [2]:
>  ## deprecation warning only when not called by method dispatch from 
> as.data.frame():
> -bdy[[2L]] <- quote(if((sys.nframe() <= 1L || 
> !identical(sys.function(-1L), as.data.frame)))
> +bdy[[2L]] <- quote(if((sys.nframe() <= 1L || !(
> + identical(sys.function(-1L), as.data.frame) || (
> + .isMethodsDispatchOn() &&
> + methods::is(sys.function(-1L), 'derivedDefaultMethod') &&
> + identical(
> + sys.function(-1L)@generic,
> + structure('as.data.frame', package = 'base')
> + )
>   .Deprecated(
>   msg = gettextf(
>   "Direct call of '%s()' is deprecated.  Use '%s()' or
>   '%s()' instead",

Of course it's "sad" to need even more "acrobatics" ... but as it
should only be temporary {but several years:
   deprecation --> defunct --> complete }
I (as "responsible" of the gymnastics) am grateful for Ivan's proposed
additional S4-related conditions.

Anybody trying S7 examples and see if they work w/o producing
wrong warnings?


> The patch passes make check-devel, but I'm not sure how to safely put
> setGeneric('as.data.frame'); as.data.frame(factor(1:10)) in a
> regression test.

{What's the danger/problem?  we do have "similar" tests in both
  src/library/methods/tests/*.R
  tests/reg-S4.R

 -- maybe we can discuss bi-laterally  (or here, as you prefer)
}

Martin

> -- 
> Best regards,
> Ivan

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

[Bioc-devel] Reminder: BioC2024 Abstract Submission and Sticker Design Contest Deadlines Approaching

[Maria . Doyle]

Hi everyone,

Just a friendly reminder about two important opportunities:

BioC2024 Abstract Submission
The deadline to submit abstracts for the North American Bioconductor Conference 
(BioC2024) is fast approaching! Don't miss your chance to present your work and 
contribute to the conference program. You can submit your abstract by March 
25th. Submit your abstract here.

BioC2024 Sticker Design Contest
Do you have a knack for design? Enter the BioC2024 Sticker Design Contest for a 
chance to showcase your creativity and win a spot at the conference. The 
deadline for submissions is also March 25th. Enter the contest 
here.

These are both fantastic opportunities to get involved with BioC2024 and make 
your mark on the conference. We encourage you to take advantage of them before 
the deadlines!

Best regards,
Maria


Maria Doyle, PhD
Bioconductor Community Manager

School of Medicine,
University of Limerick, Limerick, V94 T9PX
Ireland
Email: maria.do...@ul.ie
Phone (office): +353 61 234 768
[I work flexible hours across several time zones. I don't expect you to read or 
respond to my emails outside of your normal working hours]



[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel