Error in `signal_stage()`

[KaiWaldrant]

Since the update to version 2.0.0 we are getting an error message about signal_stage(). This seems to be a sourcecode issue:

Error in `signal_stage()`:
! `what` must be a single string, not a character vector.
Backtrace:
     ▆
  1. └─global anndataToLiger(adata)
  2.   └─rliger::createLiger(raw.data = raw_data, remove.missing = FALSE)
  3.     └─rliger:::.deprecateArgs(...)
  4.       └─lifecycle::deprecate_warn("1.99.0", what, with, always = TRUE)
  5.         └─lifecycle::signal_stage(what = what)
  6.           └─lifecycle:::spec(what, env = env)
  7.             └─lifecycle:::parse_what(spec, ctxt = ctxt)
  8.               └─lifecycle:::check_string(what, call = ctxt$call)
  9.                 └─lifecycle:::stop_input_type(x, what, ..., arg = arg, call = call)
 10.                   └─rlang::abort(message, ..., call = call, arg = arg)
Execution halted

[mvfki]

I'm not sure about what anndataToLiger() is, but we are deprecating the argument names with a dot. If you can do the object creation step manually, use rawData instead of raw.data. Please have a check at ?createLiger for other changes.

Yichen

[mvfki]

I looked into the source code once again but still couldn't figure out how this could happen, from developer's point of view. I can for sure trigger the signal_stage() error if I do lifecycle::deprecate_warn with what as a length > 1 vector. But this can only happen in rliger2.0 if the call to createLiger and the use of remove.missing are in irregular syntax, so that it might have a chance to cause such a result. However, I couldn't find the answer out without any context if I was in the right direction.

It would be helpful to diagnose and improve our future code quality if you are willing to share the sessionInfo() after the error happens. Since the anndataToLiger() function is globally defined and it's likely to be a customized thing, using the new argument names should probably be the fastest fix for you.

[KaiWaldrant]

Using the new argument names fixed it for me on my end.

The code that gave the error can be found at https://github.com/openproblems-bio/openproblems-v2/blob/main/src/tasks/batch_integration/methods/liger/script.R

SessionInfo:

R version 4.3.3 (2024-02-29)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 22.04.1 LTS

Matrix products: default
BLAS:   /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.10.0 
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.10.0

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C              
 [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8    
 [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8   
 [7] LC_PAPER=en_US.UTF-8       LC_NAME=C                 
 [9] LC_ADDRESS=C               LC_TELEPHONE=C            
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C       

time zone: UTC
tzcode source: system (glibc)

attached base packages:
[1] stats     graphics  grDevices datasets  utils     methods   base     

other attached packages:
[1] rliger_2.0.0

loaded via a namespace (and not attached):
 [1] anndata_0.7.5.6     vctrs_0.6.5         cli_3.6.2          
 [4] rlang_1.1.3         png_0.1-8           generics_0.1.3     
 [7] assertthat_0.2.1    jsonlite_1.8.8      glue_1.7.0         
[10] S4Vectors_0.40.2    colorspace_2.1-0    rprojroot_2.0.4    
[13] stats4_4.3.3        rappdirs_0.3.3      scales_1.3.0       
[16] fansi_1.0.6         grid_4.3.3          munsell_0.5.0      
[19] tibble_3.2.1        lifecycle_1.0.4     compiler_4.3.3     
[22] dplyr_1.1.4         Rcpp_1.0.12         pkgconfig_2.0.3    
[25] here_1.0.1          lattice_0.22-5      R6_2.5.1           
[28] tidyselect_1.2.1    reticulate_1.35.0   utf8_1.2.4         
[31] pillar_1.9.0        magrittr_2.0.3      Matrix_1.6-5       
[34] tools_4.3.3         gtable_0.3.4        bspm_0.5.5.1       
[37] BiocGenerics_0.48.1 ggplot2_3.5.0

[mvfki]

Nice to know that you got it fixed. Thank you very much for the information! I can reproduce bug with that source code and have got it fixed already. We are planning to release 2.0.1 within the next week for fixes on known bugs including this one.