It seems totally sensible to be able to use BiocManager to install either bioc-release or bioc-devel at any time, provided you're running R-devel. First, by definition, R-devel is always >= the R used for release / devel and Second, it is reasonable to assume users of R-devel to know what they are doing.
I am unsure if you're arguing for anything else. Best, Kasper On Thu, May 11, 2023 at 10:25 AM Wolfgang Huber <wolfgang.hu...@embl.org> wrote: > Hi Kasper > > My use case is simple: anyone who works with R-devel and wants to use a > package on Bioconductor from April to October. > Many of the 2230 packages in our repository are useful outside of the > BiocGenerics, IRanges, SummarizedExperiment core world. > E.g., to name a few, BiocParallel, illuminaio, rhdf5, EBImage, ggtree, > edgeR, limma, qvalue, sparseMatrixStats, … and I do not think “we” should > recommend people who want to use these which version of R they must use. > Btw these examples are all “highly downloaded”. > > I fully understand the wish to make people use coherent versions of > packages and R for situations where lots of interdependent packages, > classes, methods etc. are imported. > But sometimes, people just need one or two packages, and then R’s built-in > dependency management works just fine and the current BiocManager approach > is needlessly intrusive. > > It’s as bad as having made me wonder whether to recommend authors of > packages that do not directly build upon BiocGenerics, IRanges etc. to > submit them to CRAN, to increase potential user base (b/c installation from > Bioconductor can be such a pain). And that’s really not the place I want to > be. > > Thanks and best wishes > Wolfgang > > > > > > > Il giorno 10.05.2023, alle ore 17:12, Kasper Daniel Hansen < > kasperdanielhan...@gmail.com> ha scritto: > > > > Could we get a list of use cases from Wolfgang? I am confused about what > > the issue is. Is the issue that it is painful to work with R-devel in the > > "off" 6-months? If so, I agree that it should be easier (even if we don't > > recommend it). But I am having a hard time parsing the email. > > > > I can recognize Martin M's wish: a way to run Bioc-release on R-devel; > that > > seems sensible to me. > > > > Best, > > Kasper > > > > On Tue, May 9, 2023 at 3:46 AM Martin Maechler < > maech...@stat.math.ethz.ch> > > wrote: > > > >>>>>>> Wolfgang Huber > >>>>>>> on Sun, 7 May 2023 14:29:37 +0200 writes: > >> > >>> Hi Martin As you correctly point out, Bioconductor package > >>> developers are probably not those with the most relevant > >>> use cases. I think there are use cases for everyone > >>> else—anyone who decides to write code on R-devel, for > >>> whatever reason, and just wants to use a Bioconductor > >>> package between mid-April to mid-October (they could > >>> develop for CRAN, or just be a user and write scripts and > >>> packages for a private project). There are many useful > >>> packages on Bioconductor that are of general interest, > >>> even for people whose work does not center around > >>> Bioconductor or biology (say, ggtree, rhdf5, > >>> sparseMatrixStats, EBImage, …) > >> > >>> I added these ponderings also to > >>> https://github.com/Bioconductor/pkgrevdocs/issues/108 > >> > >>> Thanks and best wishes Wolfgang > >> > >> As the older ones among you know, I've been a BioC developer > >> only many years ago ('hexbin' e.g.), but as an R package > >> maintainer and co-maintainer and R Core team member, > >> I really like to chime in here, declaring that it *has* been > >> quite painful for me over the years to test CRAN packages which > >> depend on BioC packages - with R-devel -- which is my primary R > >> version for testing, notably also for testing potential changes in R > >> across many packages, etc. > >> Notably during this half of the year where there is no > >> "official" way how to correctly install current Bioconductor packages > >> (in their own package library, as I always do) under R-devel. > >> > >> If I'd be able to sum up the time lost over this issue for the last say > 10 > >> years, it would add to a full working day at least. ... > >> > >> (and I have added a comment also in the above issue #108) > >> > >> > >>> (PS in my particular case yesterday, it was just that my > >>> R-devel is better maintained (built from source etc) and > >>> has in its library some (non-BioC) packages with complex > >>> systems dependencies that I need for a workflow I am > >>> working on, packages that currently elude me on my binary > >>> installation of R4.3. And then in addition I just wanted > >>> to *use* a package from Bioconductor and didn’t like how > >>> clumsy that experience was.) > >> > >> My other experience is that I always have to help people in my > >> group to install our pcalg CRAN package because it depends > >> e.g. on Bioc packages 'graph' and 'Rgraphviz' .. and on their > >> laptops they somehow don't have the correct getOption("repos") > >> or there are other reasons why install.packages('pcalg') > >> does not find its Bioc dependencies. > >> On our Linux desktop+server environment, I do setup > >> options(repos = ....) > >> such that everything works .. but alas, also *not* when in > >> R-devel but when you develop a package for CRAN / or only just > >> follow the more wide recommendation to also check your package > >> with current R-devel, then non-expert package developers need a > >> lot of stamina if their package depends (directly or > >> recursively) on a Bioc package.... > >> which is really unfortunate and tends to put the Bioconductor > >> project in a shady light it really has not deserved at all! > >> > >> Martin > >> > >> -- > >> Martin Maechler > >> ETH Zurich and R Core team > >> > >> > >> > >>>> Il giorno 06.05.2023, alle ore 16:45, Martin Morgan > >>>> <mtmorgan.b...@gmail.com> ha scritto: > >>>> > >>>> I opened two issues for further discussion of the > >>>> technical aspects. > >>>> https://github.com/Bioconductor/BiocManager/issues/165 > >>>> https://github.com/Bioconductor/pkgrevdocs/issues/108 > >>>> Just to be clear, as noted at the end of the second issue > >>>> and on the web page you mention, a Bioconductor package > >>>> developer wishing to use 'Bioc-devel' should, during the > >>>> mid-April to mid-October release cycle, be using the > >>>> **release** version of R. This combination of R and > >>>> Bioconductor is supported by BiocManager. Similarly, in > >>>> the mid-October to mid-April release cycle, the > >>>> Bioconductor developer should be R-devel, and BoicManager > >>>> supports this, too. There are scenarios where a > >>>> developer might wish to combine R-devel and Bioc-devel in > >>>> the mid-May, to mid-October time frame, e.g., when > >>>> developing a CRAN package with Bioconductor dependencies, > >>>> or when conscientiously testing CRAN packages that depend > >>>> on Bioconductor packages. One may also just want to be on > >>>> the bleeding edge, so using R-devel and living with any > >>>> consequence that arise from R / Bioconductor version > >>>> mismatches. Are these less-common scenarios the one that > >>>> you are engaged in? Martin From: Bioc-devel > >>>> <bioc-devel-boun...@r-project.org> on behalf of Wolfgang > >>>> Huber <wolfgang.hu...@embl.org> Date: Saturday, May 6, > >>>> 2023 at 9:43 AM To: Vincent Carey > >>>> <st...@channing.harvard.edu> Cc: bioc-devel@r-project.org > >>>> <bioc-devel@r-project.org> Subject: Re: [Bioc-devel] > >>>> BiocManager::install Dear Martin and Vince > >>>> > >>>> thank you, very insightful points. Indeed I think it’s > >>>> primarily a matter of documentation and priming, and, > >>>> e.g., adding Martin's lines prominently enough e.g. to > >>>> https://contributions.bioconductor.org/use-devel.htmland > >>>> a reference to it into the manpage of > >>>> BiocMananger::install. > >>>> > >>>> I acknowledge that installation and dealing with > >>>> dependencies is *hard*. The relatively smooth user > >>>> experience of Bioconductor, compared to other projects, > >>>> is one of our greatest assets. I guess it needs constant > >>>> attention on our side. One of the slogans of > >>>> R/Bioconductor is “turning users into developers” and > >>>> therefore something that has useful defaults but is easy > >>>> enough to customize seems desirable. In that sense, it’d > >>>> be great to be able to stay with BiocManager::install and > >>>> not having to abandon it in favour of > >>>> base::install.packages. > >>>> > >>>> The codebase behind BiocManager::install seems to have > >>>> become a little…. complicated. > >>>> > >>>> The documentation clarification re > >>>> BIOCONDUCTOR_ONLINE_VERSION_DIAGNOSIS that Martin > >>>> suggests would be welcome. > >>>> > >>>> Kind regards Wolfgang > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> Il giorno 06.05.2023, alle ore 13:05, Vincent Carey > >>>> <st...@channing.harvard.edu> ha scritto: > >>>>> > >>>>> Thanks for these observations Wolfgang, I am glad I > >>>> read to the end, > because as you say, > >>>>> > >>>>> https://solutions.posit.co/envs-pkgs/bioconductor/ > >>>>> > >>>>> has lots of interesting information. As I personally > >>>> have no > experience with renv or Connect > much of the > >>>> motivating detail is opaque to me. > >>>>> > >>>>> I would question the proposition > >>>>> > >>>>> "Given the structural differences between BioConductor > >>>> and CRAN > repositories, it is not straightforward to > >>>> work with both types. " > >>>>> > >>>>> with at least 10 years of history of effective usage of > >>>> both together > by many hundreds of users. > >>>> "Straightforward" is > subjective. The existence of some > >>>> shortcomings, like the specific > ones you mention, is > >>>> acknowledged, and setting > up priorities to ameliorate > >>>> them would be worthwhile. Part of the > prioritization > >>>> would need to be based on user > data and user > >>>> experiences. In the case of this posit.co article, what > >>>>> is known about the significance of Connect > for > >>>> genomic data science? I have not had great difficulty > >>>> publishing > apps to shinyapps.io that use Bioconductor > > >>>> and CRAN, but perhaps it can be made easier if that is a > >>>> key concern. > >>>>> > >>>>> The problem of smoothly supporting multiple versions of > >>>> R/Bioc > simultaneously is also acknowledged. At this > > >>>> time we do not have sufficient resources to make a big > >>>> charge in the > direction of increasing support for this > >>>>> "use case". Users and sysadmins with sufficient > >>>> expertise can > definitely accomplish much in this area, > >>>> see > > >>>> https://bioconductor.org/about/release-announcements/ for > >>>> the map of > resources supporting this going back to > > >>>> 2005. If there is a way to simplify this by using > >>>> recently developed > package management strategies is > >>>> would > be good to know and document. > >>>>> > >>>>> This is a good place to continue the discussion from a > >>>> developer's > perspective, but how can we get more > > >>>> input from non-developer users? And from posit.co? > >>>>> > >>>>> "Publishing Shiny Apps that make use of BioConductor > >>>> packages to > Connect is not possible for this setup. > > >>>> BiocManager::install() temporarily adds the BioConductor > >>>> repository > for the duration of the install process. > > >>>> During the publishing process rsconnect no longer has any > >>>> knowledge > about BioConductor." -- is this something > > >>>> that can be remedied in BiocManager? Are we able to test > >>>> Connect for > this use case? > >>>>> > >>>>> > >>>>> On Sat, May 6, 2023 at 4:40 AM Wolfgang Huber > >>>> <wolfgang.hu...@embl.org> wrote: > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> I am wondering whether: >> 1. it could be easier to > >>>> install Bioconductor packages (devel or release) on > >>>> R-devel (or other non-standard R versions) using > >>>> BiocManager::install (I may be stirring a hornet’s nest > >>>> with that:) >> 2. whether its documentation needs to be > >>>> updated and/or its implementation could be deconvoluted > >>>> (hopefully that’s uncontroversial). > >>>>>> > >>>>>> Re the first point, I appreciate that we’re trying to > >>>> help non-expert users with simple use cases, and that we > >>>> had/have a lot of trouble with users working with > >>>> out-of-sync versions. OTOH, the current solution (rigid, > >>>> confusing documentation, seemingly buggy implementation) > >>>> seems to be standing in the way for developers, a > >>>> dichotomy that we do not really want. > >>>>>> > >>>>>> Of course, a workaround is >> ```{r} >>> > >>>> install.packages("ggtree", repos = c(“@CRAN@", > >>>> "https://bioconductor.org/packages/3.18/bioc") >> ``` >> > >>>> and maybe this is just the answer. So far, my workflows > >>>> have been based on BiocManager::install, but I get (and > >>>> cannot seem to get rid of): > >>>>>> > >>>>>> ```{r} >>> > >>>> options(BIOCONDUCTOR_ONLINE_VERSION_DIAGNOSIS = FALSE) > >>>>>>> BiocManager::install("ggtree", version = "devel") >> > >>>> Error: Bioconductor does not yet build and check packages > >>>> for R version 4.4; see >> > >>>> https://bioconductor.org/install > >>>>>> > >>>>>>> sessionInfo() >> R Under development (unstable) > >>>> (2023-05-05 r84398) >> Platform: aarch64-apple-darwin20 > >>>> (64-bit) >> Running under: macOS Ventura 13.3.1 > >>>>>> > >>>>>> Matrix products: default >> BLAS: > >>>> > >> > /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib > >>>>>> LAPACK: > >>>> > >> /Users/whuber/R.framework/Versions/4.4/Resources/lib/libRlapack.dylib; > >>>> LAPACK version 3.11.0 > >>>>>> > >>>>>> locale: >> [1] > >>>> en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8 > >>>>>> > >>>>>> time zone: Europe/Berlin >> tzcode source: internal > >>>>>> > >>>>>> attached base packages: >> [1] stats graphics > >>>> grDevices utils datasets methods base > >>>>>> > >>>>>> other attached packages: >> [1] BiocManager_1.30.20 > >>>> fortunes_1.5-4 > >>>>>> > >>>>>> loaded via a namespace (and not attached): >> [1] > >>>> compiler_4.4.0 tools_4.4.0 rstudioapi_0.14 >> ``` > >>>>>> > >>>>>> I noted some discussion on this here: > >>>> https://github.com/Bioconductor/BiocManager/issues/13 but > >>>> this was 5 years ago. >> It appears that the > >>>> documentation of BiocManager::install mismatches its > >>>> implementation, and overall the process for something > >>>> that's conceptually quite simple seems to have become > >>>> convoluted. > >>>>>> > >>>>>> One of the most helpful documentation resources on > >>>> this topic btw is > >>>> https://solutions.posit.co/envs-pkgs/bioconductor/ which > >>>> cheerfully concludes "Working with BioConductor packages > >>>> for code development is possible." > >>>>>> > >>>>>> Thanks and best wishes >> Wolfgang > >>>>>> > >>>>>> -- > >>>>>> Wolfgang Huber >> EMBL >> > >>>> https://www.embl.org/groups/huber > >>>>>> > >>>>>> _______________________________________________ >> > >>>> Bioc-devel@r-project.org mailing list >> > >>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel > >>>>> > >>>>> -- > >>>>> The information in this e-mail is intended only for > >>>> th...{{dropped:17}} > >>>> > >>>> _______________________________________________ > >>>> Bioc-devel@r-project.org mailing list > >>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel > >> > >>> _______________________________________________ > >>> Bioc-devel@r-project.org mailing list > >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel > >> > >> _______________________________________________ > >> Bioc-devel@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/bioc-devel > >> > > > > > > -- > > Best, > > Kasper > > > > [[alternative HTML version deleted]] > > > > _______________________________________________ > > Bioc-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/bioc-devel > > -- Best, Kasper [[alternative HTML version deleted]] _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel