[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
Thu Oct 12 21:33:04 CEST 2023
On 10/12/23 12:25, Zuguang Gu wrote:
> The devel version of DOSE depends on MPO.db.
>
> I also found MoonlightR depends on DOSE only on its two functions:
> gseDO() and simplot().
>
> An analysis by the pkgndep package shows if you can reduce the
> dependency on both clusterProfiler and DOSE, a total of 46 upstream
> dependencies will be reduced (30 by clusterProfiler uniquely and 16 by
> both). You can use `pkgndep::dependency_database()` to query the
> dependencies, but the database was only updated to some version last year.
>
> MPO.db initializes an instance of AnnotationHub in its .onLoad(). I
> don't know whether that is the source of the error.
>
> .onLoad <- function(libname, pkgname) {
> ns <- asNamespace(pkgname)
> makeCachedActiveBinding("MPO.db", make_MPO.db, env=ns)
> namespaceExport(ns, "MPO.db")
> ah <- suppressMessages(AnnotationHub())
> dbfile <- ah[["AH111553", verbose=FALSE]]
> dbconn <- AnnotationDbi::dbFileConnect(dbfile)
> assign("dbconn", dbconn, envir=datacache)
> ann_objs <- createAnnObjs.MPO_DB("MPO", "MPO", dbconn, datacache)
> mergeToNamespaceAndExport(ann_objs, "MPO.db")
>
> }
I don't know either but we strongly recommend against .onLoad hooks
trying to access the internet. Once a package is installed, one should
be able to load it offline.
H.
>
>
> On Thu, 12 Oct 2023 at 20:37, Robert Castelo <robert.castelo using upf.edu>
> wrote:
>
> Hi,
>
> one of the kind of tools that Hervé is referring to is the package
> BiocPkgTools:
>
> https://bioconductor.org/packages/BiocPkgTools
>
> section "7 Dependency burden" in the vignette illustrates how to
> identify dependencies that you might want to get rid of.
>
> cheers,
>
> robert.
>
> On 12/10/23 18:24, Hervé Pagès wrote:
> > 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
> <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/> | Our privacy
> >> policy <https://www.cancer.dk/om-os/privatlivspolitik/>
> >>
> >> *From: *Hervé Pagès <hpages.on.github using gmail.com>
> >> *Date: *Wednesday, 11 October 2023 at 19.30
> >> *To: *Matteo Tiberti <tiberti using cancer.dk>, bioc-devel using r-project.org
> >> <bioc-devel using 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 using 01D9FB90.6FE2D7A0
> >>
> <cid:image001.png using 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>>
> >>
> <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>
> >> <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 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
> >
>
> --
> Robert Castelo, PhD
> Associate Professor
> Dept. of Medicine and Life Sciences
> Universitat Pompeu Fabra (UPF)
> Barcelona Biomedical Research Park (PRBB)
> Dr Aiguader 88
> E-08003 Barcelona, Spain
> telf: +34.933.160.514
>
> _______________________________________________
> 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