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.cast...@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.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>> > >> > > <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@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/bioc-devel > >> > >> -- > >> Hervé Pagès > >> Bioconductor Core Team > >> hpages.on.git...@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@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com [[alternative HTML version deleted]] _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel