[Bioc-devel] arm64 on Mac build fails due to problem with MPO.db
Hervé Pagès
hp@ge@@on@g|thub @end|ng |rom gm@||@com
Wed Oct 11 19:30:33 CEST 2023
Hi Matteo,
Thanks for letting us know.
FWIW the dependency on MPO.db is via clusterProfiler and DOSE.
Not directly addressing the issue but note that clusterProfiler is a
heavy-weight dependency that triggers the loading of 120+ packages. All
together, loading Moonlight2R with library(Moonlight2R) triggers the
loading of 170+ packages which takes about 20 seconds.
Have you considered trying to make Moonlight2R dependencies lighter? For
example it seems that the only thing that the package uses from
clusterProfiler is clusterProfiler::bitr(), which is a simple
convenience wrapper around AnnotationDbi::select() used inside your
GSEA() function. I wonder if some of these deps could perhaps be moved
from Imports to Suggests, with the hope to make library(Moonlight2R)
lighter and faster.
Best,
H.
On 10/11/23 02:18, Matteo Tiberti via Bioc-devel wrote:
> Dear all,
>
> We are seeing a couple of build fails of our MoonlightR and
> Moonlight2R packages in the devel (3.18) MacOS arm64 builder that seem
> to be related to the MPO.db package. This is the error message we get:
>
> * installing to library
> ‘/Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/library’
> * installing *source* package ‘Moonlight2R’ ...
> ** using staged installation
> ** R
> ** data
> ** inst
> ** byte-compile and prepare package for lazy loading
> Warning: Couldn't set cache size: file is not a database
> Use `cache_size` = NULL to turn off this warning.
> Warning: Couldn't set synchronous mode: file is not a database
> Use `synchronous` = NULL to turn off this warning.
> Error: .onLoad failed in loadNamespace() for 'MPO.db', details:
> call: NULL
> error: file is not a database
> Execution halted
> ERROR: lazy loading failed for package ‘Moonlight2R’
> * removing
> ‘/Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/library/Moonlight2R’
>
> We don’t have MPO.db as an explicit requirement for our packages, and
> it checks all green on its own build report. We poked around 3.18
> MacOS arm64 build reports and saw several other packages with similar
> failures (e.g.
> miRspongeR<https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/miRspongeR/>
> miRSM<https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/miRSM/>
> MicrobiomeProfiler<https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/MicrobiomeProfiler/>
> EasyCellType<https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/EasyCellType/>
> MetaPhOR<https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/MetaPhOR/>
> meshes<https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/meshes/>
> CBNplot<https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/CBNplot/>
> …) so we were wondering if there’s a more general problem with the
> builder/set up or if there is a general solution to this. Suggestions
> are welcome
>
> Thank you,
>
> Matteo Tiberti
>
> Danish Cancer Institute
> Strandboulevarden 49
> DK-2100 Copenhagen
> Telephone: +45 35 25 73 07
> – a part of the Danish Cancer Society
>
> [cid:image001.png using 01D9FB90.6FE2D7A0]<https://www.cancer.dk/?utm_source=email&utm_medium=medarbejderemail&utm_campaign=medarbejderemail&utm_content=cancerdk>
>
>
> www.cancer.dk<https://www.cancer.dk/international/> | Our privacy
> policy<https://www.cancer.dk/om-os/privatlivspolitik/>
>
> _______________________________________________
> Bioc-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
--
Hervé Pagès
Bioconductor Core Team
hpages.on.github using gmail.com
[[alternative HTML version deleted]]
More information about the Bioc-devel
mailing list