On 10/12/23 00:45, Matteo Tiberti wrote:
Hi Hervé,
Thank you for your comment and for looking into our package – it would
definitely make sense to try and not depend on clusterProfiler if it
is that heavy of a dependency (and we don’t use it so much as you
mention), more in general working in the direction of removing
little-used or heavy dependencies would speed things up all around and
reduce the chance of having failures because of changes/failures of
dep. packages. We will try and reassess the package imports in this
direction.
It would be great if we could obtain e.g. a dependency graph – or at
least know how many (unique) dependencies each of our deps has, e.g. I
saw that miniCRAN can do something similar
I think there are a number of tools already that you can use to do this
kind of analysis e.g. basic low-level tools like
tools::package_dependencies() but also more high-level ones with
advanced functionalities like pkgndep (CRAN package) etc...
H.
Best,
Matteo Tiberti
*Danish Cancer Institute*
Strandboulevarden 49
DK-2100 Copenhagen
*Telephone*: +45 35 25 73 07
/– a part of the Danish Cancer Society/
<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/>
*From: *Hervé Pagès <hpages.on.git...@gmail.com>
*Date: *Wednesday, 11 October 2023 at 19.30
*To: *Matteo Tiberti <tibe...@cancer.dk>, bioc-devel@r-project.org
<bioc-devel@r-project.org>
*Subject: *Re: [Bioc-devel] arm64 on Mac build fails due to problem
with MPO.db
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/>
<https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/miRspongeR/>
miRSM<https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/miRSM/>
<https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/miRSM/>
MicrobiomeProfiler<https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/MicrobiomeProfiler/>
<https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/MicrobiomeProfiler/>
EasyCellType<https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/EasyCellType/>
<https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/EasyCellType/>
MetaPhOR<https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/MetaPhOR/>
<https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/MetaPhOR/>
meshes<https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/meshes/>
<https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/meshes/>
CBNplot<https://bioconductor.org/checkResults/3.18/bioc-mac-arm64-LATEST/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@01D9FB90.6FE2D7A0
<cid:image001.png@01D9FB90.6FE2D7A0>]<https://www.cancer.dk/?utm_source=email&utm_medium=medarbejderemail&utm_campaign=medarbejderemail&utm_content=cancerdk>
<https://www.cancer.dk/?utm_source=email&utm_medium=medarbejderemail&utm_campaign=medarbejderemail&utm_content=cancerdk>
www.cancer.dk
<http://www.cancer.dk><https://www.cancer.dk/international/>
<https://www.cancer.dk/international/> | Our privacy
policy<https://www.cancer.dk/om-os/privatlivspolitik/>
<https://www.cancer.dk/om-os/privatlivspolitik/>
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
--
Hervé Pagès
Bioconductor Core Team
hpages.on.git...@gmail.com
--
Hervé Pagès
Bioconductor Core Team
hpages.on.git...@gmail.com
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
