[Bioc-devel] BiocManager::install

[Klaus Schliep]

Hi all,
no real contribution to this discussion, just some appreciation to all your
hard work.
I just wish CRAN had something like a proper release cycle for packages. I
contribute to two packages phangorn and ape, which have a decent number of
reverse dependencies. So you can't introduce any breaking changes (as there
is no devel branch) without contacting all maintainers and fixing some/most
reverse dependencies yourself. Also whenever CRAN introduces a change to
R-devel which causes an error of your package, one and sometime all
maintainers of dependent packages might get an email stating to fix this
within 2 weeks. This however has nothing to do with their release cycle of
the new R version itself. I wonder how many packages have been taken from
CRAN and how much total unnecessary frustration this causes?
Have a nice weekend.
Kind regards,
Klaus Schliep

On Sat, May 6, 2023 at 10:40 AM Wolfgang Huber <wolfgang.huber using 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 using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>


-- 
Klaus Schliep

Senior Scientist
Institute of Molecular Biotechnology
TU Graz
https://www.imbt.tugraz.at

	[[alternative HTML version deleted]]