I think it's a per-dependency judgement call. If you're making broad use of a package, then it makes sense to import(), but if the dependency on some package is minimal, it makes sense to specify symbols with importFrom(), as the link is more tenuous and there is less risk to things moving around.
On Wed, Jul 16, 2014 at 11:59 AM, Martin Morgan <mtmor...@fhcrc.org> wrote: > On 07/16/2014 11:39 AM, Leonardo Collado Torres wrote: > >> Hi Tengfei and BioC-devel, >> >> ggbio 1.13.11 fails to load due to recent changes in IRanges' >> namespace as shown further below. Basically, some of IRanges previous >> code now lives in S4Vectors. >> >> On a recent thread Hervé exposed his view on specific imports versus >> importing the whole package (see >> https://stat.ethz.ch/pipermail/bioc-devel/2014-July/005943.html and >> Stephanie's reply >> https://stat.ethz.ch/pipermail/bioc-devel/2014-July/005948.html ). >> >> I have been using specific imports because I thought it was the best >> practice and that it would also help me learn more about what are the >> functions/methods I'm relying on exactly. But as Hervé exposed, using >> specific imports involves a lot of maintenance overhead. That is why, >> in general I'll try to use general imports now. >> > > That should really be a judgement call -- a nice tidy package might well > import a very limited number of functions from a small number of packages, > with the use of each function limited to specific and well-know locations, > and with changes to the code being very considered -- I no longer need to > import pkg::foo because I made a very specific change to the code. Indeed > for less experienced developers it might be worth focusing on this as a > kind of discipline -- write code that _is_ restricted in this way, doing a > small number of tasks well rather than trying to do everything. > > For the large and comprehensive packages Herve and others work on, this > will certainly get tedious. For a more focused developer it is perhaps not > so bad. > > Martin > > > >> Cheers, >> Leo >> >> >> >> library(ggbio) >>> >> Loading required package: BiocGenerics >> Loading required package: parallel >> >> Attaching package: âBiocGenericsâ >> >> The following objects are masked from âpackage:parallelâ: >> >> clusterApply, clusterApplyLB, clusterCall, clusterEvalQ, >> clusterExport, clusterMap, parApply, parCapply, parLapply, >> parLapplyLB, parRapply, parSapply, parSapplyLB >> >> The following object is masked from âpackage:statsâ: >> >> xtabs >> >> The following objects are masked from âpackage:baseâ: >> >> anyDuplicated, append, as.data.frame, as.vector, cbind, colnames, >> do.call, duplicated, eval, evalq, Filter, Find, get, >> intersect, is.unsorted, lapply, Map, mapply, match, mget, order, >> paste, pmax, pmax.int, pmin, pmin.int, Position, rank, >> rbind, Reduce, rep.int, rownames, sapply, setdiff, sort, table, >> tapply, union, unique, unlist >> >> Loading required package: ggplot2 >> No methods found in "IRanges" for requests: Rle, substring, ifelse, >> as.factor >> Error : object ârunValueâ is not exported by 'namespace:IRanges' >> Error: package or namespace load failed for âggbioâ >> >>> traceback() >>> >> 2: stop(gettextf("package or namespace load failed for %s", >> sQuote(package)), >> call. = FALSE, domain = NA) >> 1: library(ggbio) >> >>> sessionInfo() >>> >> R version 3.1.0 (2014-04-10) >> Platform: x86_64-apple-darwin10.8.0 (64-bit) >> >> locale: >> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8 >> >> attached base packages: >> [1] parallel stats graphics grDevices utils datasets >> methods base >> >> other attached packages: >> [1] ggplot2_1.0.0 BiocGenerics_0.11.3 >> >> loaded via a namespace (and not attached): >> [1] AnnotationDbi_1.27.8 BatchJobs_1.3 BBmisc_1.7 >> Biobase_2.25.0 BiocParallel_0.7.7 >> [6] biomaRt_2.21.1 Biostrings_2.33.12 bitops_1.0-6 >> brew_1.0-6 BSgenome_1.33.8 >> [11] checkmate_1.1 cluster_1.15.2 codetools_0.2-8 >> colorspace_1.2-4 DBI_0.2-7 >> [16] dichromat_2.0-0 digest_0.6.4 fail_1.2 >> foreach_1.4.2 Formula_1.1-2 >> [21] GenomeInfoDb_1.1.12 GenomicAlignments_1.1.21 >> GenomicFeatures_1.17.12 GenomicRanges_1.17.24 GGally_0.4.6 >> [26] grid_3.1.0 gridExtra_0.9.1 gtable_0.1.2 >> Hmisc_3.14-4 IRanges_1.99.22 >> [31] iterators_1.0.7 lattice_0.20-29 >> latticeExtra_0.6-26 MASS_7.3-33 munsell_0.4.2 >> [36] plyr_1.8.1 proto_0.3-10 >> RColorBrewer_1.0-5 Rcpp_0.11.2 RCurl_1.95-4.1 >> [41] reshape_0.8.5 reshape2_1.4 >> Rsamtools_1.17.31 RSQLite_0.11.4 rtracklayer_1.25.13 >> [46] S4Vectors_0.1.2 scales_0.2.4 sendmailR_1.1-2 >> splines_3.1.0 stats4_3.1.0 >> [51] stringr_0.6.2 survival_2.37-7 tools_3.1.0 >> XML_3.98-1.1 XVector_0.5.7 >> [56] zlibbioc_1.11.1 >> >>> >>> packageVersion("ggbio") >>> >> [1] â1.13.11â >> >>> >>> >> _______________________________________________ >> Bioc-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/bioc-devel >> >> > > -- > Computational Biology / Fred Hutchinson Cancer Research Center > 1100 Fairview Ave. N. > PO Box 19024 Seattle, WA 98109 > > Location: Arnold Building M1 B861 > Phone: (206) 667-2793 > > > _______________________________________________ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > [[alternative HTML version deleted]]
_______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
