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.html and 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
