Dear Klaus
Good points. I am not trying to “poach” anything here, and guess you have
discussed this, but with this number of reverse dependencies, it sounds like
the maintainers, contributors and users of ape and phangorn could benefit from
putting the packages on Bioconductor?
>From a quick look it seems that a good fraction of their reverse dependencies
>are on Bioconductor, and also the remaining ones might benefit from you being
>able to follow the established and transparent devel/release cycle?
Thanks and best wishes
Wolfgang
> Il giorno 12.05.2023, alle ore 17:19, Klaus Schliep <klaus.schl...@gmail.com>
> ha scritto:
>
> 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.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
>>
>
>
> --
> Klaus Schliep
>
> Senior Scientist
> Institute of Molecular Biotechnology
> TU Graz
> https://www.imbt.tugraz.at
>
> [[alternative HTML version deleted]]
>
> _______________________________________________
> 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
