Package dependencies not installed

[JABioinf]

Hi team, Thank you for developing this nice tool!
I tried to install it using conda with r 4.5:
conda create --name r_env_bioc r-base r-essentials conda-forge::r-biocmanager
Then sucessfully installed decoupleR:
BiocManager::install('saezlab/decoupleR')
Yet when I run AUcell the package is not installed:

run_aucell(mat, net, minsize=0, nproc=1, aucMaxRank=3)
Error in loadNamespace(x) : there is no package called ‘AUCell’

Isn't that supposed to be install alongside decoupleR ? there is no mention of it in the package install description.
Could you list the way to install all necessary packages to run all methods listed and to make sure versions are compatible with decoupleR ?
Thanks!

[deeenes]

Method specific dependencies are listed under the Suggests section in DESCRIPTION, to enable a lightweight default installation of the package. Provide the dependencies = TRUE argument to install.packages to also install the suggested dependencies:

BiocManager::install('saezlab/decoupleR', dependencies = TRUE)

[JABioinf]

Thank you!
I tried the BiocManager install in R 4.5 but it fails on install XML among others.
In R 4.4 using BiocManager inside R failed on many packages, but I managed to install most of the complex packages (aucell, viper, magick, gsva, etc.) through some conda install bioconda::bioconductor-*** (some of those issues could be associated with using a conda setup).

Would be great if you had a stable install of all extended packages to run all methods available in decoupleR wrapped up in a docker/singularity image (but that's extra work, of course, so thanks for already making everything available in the current form).

[deeenes]

Since you use conda, would you be fine with switching to Python? Decoupler's Python implementation has much better performance, API and features. Or if you want to stay with R, why do you use conda? It complicates things a lot because all path config becomes much more complex (all of CPATH, LD_LIBRARY_PATH, R_LIBS_USER and PYTHONPATH). For example, the failure to install XML sounds exactly like a path issue.

Indeed a container could be an option, though in this case sounds a bit of an overkill. Still, it's not unrealistic to create a standard CI workflow to do it for all our packages. Actually a Docker container with most of our tools installed exists, though it might be either outdated or broken, we have no idea if anyone uses it at all.