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
(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.)
> Il giorno 06.05.2023, alle ore 16:45, Martin Morgan
> 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 on behalf of Wolfgang
> Huber
> Date: Saturday, May 6, 2023 at 9:43 AM
> To: Vincent Carey
> Cc: 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
> > 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
