Re: [Bioc-devel] BiocManager::install
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
> 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
> 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
Re: [Bioc-devel] BiocManager::install
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
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
Re: [Bioc-devel] BiocManager::install
> Il giorno 12.05.2023, alle ore 04:43, Kasper Daniel Hansen > ha scritto: > > 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. Hi Kasper, Nope, that’s it. Was I so unclear? Wolfgang. ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] BiocManager::install
urce 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
> >>>> 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
Re: [Bioc-devel] BiocManager::install
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 >>>> 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 >
Re: [Bioc-devel] BiocManager::install
nductor 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 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 sufficie
Re: [Bioc-devel] BiocManager::install
>>>>> 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
>> 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.
Re: [Bioc-devel] BiocManager::install
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 amelio
Re: [Bioc-devel] BiocManager::install
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.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 > 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 te
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.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
> 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 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:
Re: [Bioc-devel] BiocManager::install
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 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
Re: [Bioc-devel] BiocManager::install
For off-piste use I would have consulted `setRepositories(graphics = FALSE)`
and then
```
## use Sys.setenv() before setRepositories
Sys.setenv(R_BIOC_VERSION="3.18")
setRepositories(ind = 1:4) # CRAN plus Bioc soft, anno, and expt repos
getOption("repos")# check
install.packages("BiocGenerics")
```
The help page ?BIOCONDUCTOR_ONLINE_VERSION_DIAGNOSIS says
�BIOCONDUCTOR_ONLINE_VERSION_DIAGNOSIS� is an environment variable
or global �options()� which, when set to �FALSE�, avoids the R and
_Bioconductor_ version checks that are done by querying an online
configuration file. Setting
�BIOCONDUCTOR_ONLINE_VERSION_DIAGNOSIS� to �FALSE� can speed
package loading when internet access is slow or non-existent, but
may result in out-of-date information about the current release
and development versions of _Bioconductor_. Offline users should
set the �BIOCONDUCTOR_CONFIG_FILE� environment variable or option
to a �.yaml� file similar to
https://bioconductor.org/config.yaml for full offline use and
version validation.
This could be clarified to more clearly indicate that
BIOCONDUCTOR_ONLINE_VERSION_DIAGNOSIS replaces the online version check with a
local check against BIOCONDUCTOR_CONFIG_FILE; it does not disable the check. If
you've copied the online file to a local file verbatim, then the same
constraints are validated but without going online.
The use case that this is meant to support is when the Bioconductor repository
(options(BioC_mirror = �)) is itself off-line or not internet accessible, as
might be the case in a corporate or HPC environment where a local mirror is
maintained on the file system or inside a firewall.
One could hack the local config file in a more or less obvious way (replace
"3.18" : "4.3" in the r_ver_for_bioc_ver section) but I would do something less
easily forgotten.
FWIW I don't think BiocManager should support non-standard installations,
keeping most users on track but letting the experts fend for themselves.
Martin
From: Bioc-devel on behalf of Wolfgang Huber
Date: Saturday, May 6, 2023 at 4:40 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] BiocManager::install
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] BiocManager::install
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
Re: [Bioc-devel] BiocManager::install() behavior with available updates
Hi Matej,
Usually when I find this kind of message it indicates that the package
is installed in different libraries and you are updating in just one
library.
Have you checked that it is installed in multiple libraries? I usually
use something similar to this to identify those packages:
ip1 <- installed.packages(lib = .libPaths()[1])
ip2 <- installed.packages(lib = .libPaths()[2])
union(rownames(ip1), rownames(ip2))
I hope this helps.
Best,
Lluís
On Sat, 12 Nov 2022 at 17:37, Matej Lexa wrote:
>
> Dear all,
>
> I encountered strange behavior of BiocManager::install(). When I ask it
> to install a package that is flagged as one with available updates, it
> gives me the option to upgrade immediately after I install the latest
> version. Not a big deal but thought it should not offer that
> possibility. See my latest test:
>
> ==
>
> > BiocManager::install("VennDiagram")
> 'getOption("repos")' replaces Bioconductor standard repositories, see
> '?repositories' for details
>
> replacement repositories:
> CRAN: https://cloud.r-project.org
>
> Bioconductor version 3.16 (BiocManager 1.30.19), R 4.2.2 (2022-10-31)
> Installing package(s) 'VennDiagram'
> trying URL
> 'https://cloud.r-project.org/src/contrib/VennDiagram_1.7.3.tar.gz'
> Content type 'application/x-gzip' length 78508 bytes (76 KB)
> ==
> downloaded 76 KB
>
> * installing *source* package ‘VennDiagram’ ...
> ** package ‘VennDiagram’ successfully unpacked and MD5 sums checked
> ** using staged installation
> ** R
> ** data
> ** byte-compile and prepare package for lazy loading
> ** help
> *** installing help indices
> ** building package indices
> ** testing if installed package can be loaded from temporary location
> ** testing if installed package can be loaded from final location
> ** testing if installed package keeps a record of temporary installation
> path
> * DONE (VennDiagram)
>
> The downloaded source packages are in
> ‘/tmp/RtmpaW1s0x/downloaded_packages’
> Old packages: 'VennDiagram'
> Update all/some/none? [a/s/n]: a
>
> ___
> 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] BiocManager::install() behavior with available updates
Dear all,
I encountered strange behavior of BiocManager::install(). When I ask it
to install a package that is flagged as one with available updates, it
gives me the option to upgrade immediately after I install the latest
version. Not a big deal but thought it should not offer that
possibility. See my latest test:
==
> BiocManager::install("VennDiagram")
'getOption("repos")' replaces Bioconductor standard repositories, see
'?repositories' for details
replacement repositories:
CRAN: https://cloud.r-project.org
Bioconductor version 3.16 (BiocManager 1.30.19), R 4.2.2 (2022-10-31)
Installing package(s) 'VennDiagram'
trying URL
'https://cloud.r-project.org/src/contrib/VennDiagram_1.7.3.tar.gz'
Content type 'application/x-gzip' length 78508 bytes (76 KB)
==
downloaded 76 KB
* installing *source* package ‘VennDiagram’ ...
** package ‘VennDiagram’ successfully unpacked and MD5 sums checked
** using staged installation
** R
** data
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded from temporary location
** testing if installed package can be loaded from final location
** testing if installed package keeps a record of temporary installation
path
* DONE (VennDiagram)
The downloaded source packages are in
‘/tmp/RtmpaW1s0x/downloaded_packages’
Old packages: 'VennDiagram'
Update all/some/none? [a/s/n]: a
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] BiocManager::install() downgrade installed packages
If it were me I might update version
BiocManager::install(version="3.10")
...
Update xxx packages [y/n]: n
Confirm I've got the right version
BiocManager::version()
and then recover the URLs
BiocManager::repositories()
as arguments to install.packages(). It doesn't make sense to ask for
repositories(version="...") if that's not the version BiocManager knows about...
Martin
On 10/31/19, 3:54 PM, "Bioc-devel on behalf of Henrik Bengtsson"
wrote:
On Thu, Oct 31, 2019 at 11:52 AM James W. MacDonald wrote:
>
> The main goal for BiocManager is to help end users ensure that their
R/BioC installation is consistent for the version of R that they are using. So
by definition, any packages that are outside the versions for a given R/BioC
installation should be up or down-graded to make the installation valid. There
are those of us who are l33t enough to mix'n'match packages and debug errors
that may then occur. But it's probably not a good idea to make it easily hacked
by naive users, allowing them to do things that might cause problems.
>
> Anyway, I believe doing
>
> options("BIOCMANAGER_CRANCHECK_BEHAVIOR" = FALSE)
>
> will stop BiocManager::install from changing any installed CRAN packages.
And it's suitably obscure to limit that to the cool kids who can find it.
Unfortunately, this doesn't seem to make a difference. By searching
the GitHub code base it doesn't look like this option is used
anywhere:
https://github.com/search?q=org%3ABioconductor+BIOCMANAGER_CRANCHECK_BEHAVIOR=Code
My current workaround it to not use BiocManager and roll my own
'repos' settings;
> unname(getOption("repos"))
[1] "https://cloud.r-project.org;
[2] "https://bioconductor.org/packages/3.10/bioc;
[3] "https://bioconductor.org/packages/3.10/data/annotation;
[4] "https://bioconductor.org/packages/3.10/data/experiment;
[5] "https://bioconductor.org/packages/3.10/workflows;
and use good old update.packages().
Alternative wish: It would be handy if there was a
BiocManager::repositories(version = "3.10") for finding these,
especially since some of them come and go depending on Bioc version.
/Henrik
PS. I also tried setting ditto env var because it looked more like an
env var than R option name to me.
>
> On Thu, Oct 31, 2019 at 2:21 PM Henrik Bengtsson
wrote:
>>
>> (posting this here since I think it's not a support question per se)
>>
>> Hi, I just started an upgrade from Bioc 3.9 to 3.10 on my local R 3.6.1
setup:
>>
>> > BiocManager::install(version = "3.10")
>> Upgrade 73 packages to Bioconductor version '3.10'? [y/n]: y
>> Bioconductor version 3.10 (BiocManager 1.30.9), R 3.6.1 Patched
(2019-09-12
>> r77183)
>> Installing package(s) 'BiocVersion'
>> ...
>> Installing package(s) 'base64enc', 'future', 'future.callr', 'listenv',
>> 'matrixStats', 'munsell', 'png', 'profmem', 'R.oo', 'rcmdcheck',
'scales',
>> 'affxparser', 'affy', 'affyio', 'AffymetrixDataTestFiles', 'annotate',
>> 'AnnotationDbi', 'AnnotationForge', 'aroma.light', 'Biobase',
'BiocCheck',
>> 'BiocGenerics', 'BiocParallel', 'BiocStyle', 'BiocVersion',
'biocViews',
>> 'Biostrings', 'BSgenome', 'CGHbase', 'CGHcall', 'cytolib',
'DelayedArray',
>> 'DNAcopy', 'edgeR', 'flowCore', 'flowViz', 'genefilter',
'GenomeInfoDb',
>> 'GenomeInfoDbData', 'GenomicAlignments', 'GenomicRanges', 'GO.db',
'graph',
>> 'GSEABase', 'IlluminaDataTestFiles', 'illuminaio', 'impute', 'IRanges',
>> 'limma', 'marray', 'ncdfFlow', 'oligo', 'oligoClasses', 'org.Hs.eg.db',
>> 'pdInfoBuilder', 'preprocessCore', 'QDNAseq', 'QDNAseq.hg19',
'QDNAseq.mm10',
>> 'RBGL', 'Rgraphviz', 'Rhdf5lib', 'Rhtslib', 'RProtoBufLib',
'Rsamtools',
>> 'rtracklayer', 'S4Vectors', 'ShortRead', 'STROMA4',
'SummarizedExperiment',
>> 'XVector', 'zlibbioc'
>> trying URL
'https://cloud.r-project.org/src/contrib/base64enc_0.1-3.tar.gz'
>> Content type 'application/x-gzip' length 7833 bytes
>> ==
>> downloaded 7833 bytes
>>
>> trying URL 'https://cloud.r-project.org/src/contrib/future_1.14.0.tar.gz'
>> Content type 'application/x-gzip' length 294967 bytes (288 KB)
>> ==
>> downloaded 288 KB
>> ...
>>
>> It surprised me that BiocManager::install() will _downgrade_ to CRAN(*)
>> package versions, even if you have newer versions installed. For
>> instance, I've got base64enc 0.1.4 from
>> http://www.rforge.net/base64enc/, my own development version of future
>> 1.14.0-9000, and so on. Note that the prompt says nothing about
>> downgrading. Is this really wanted and is there a way to avoid this?
>>
>> (*) Will this also downgrade Bioc developers' Bioc
Re: [Bioc-devel] BiocManager::install() downgrade installed packages
On Thu, Oct 31, 2019 at 11:52 AM James W. MacDonald wrote:
>
> The main goal for BiocManager is to help end users ensure that their R/BioC
> installation is consistent for the version of R that they are using. So by
> definition, any packages that are outside the versions for a given R/BioC
> installation should be up or down-graded to make the installation valid.
> There are those of us who are l33t enough to mix'n'match packages and debug
> errors that may then occur. But it's probably not a good idea to make it
> easily hacked by naive users, allowing them to do things that might cause
> problems.
>
> Anyway, I believe doing
>
> options("BIOCMANAGER_CRANCHECK_BEHAVIOR" = FALSE)
>
> will stop BiocManager::install from changing any installed CRAN packages. And
> it's suitably obscure to limit that to the cool kids who can find it.
Unfortunately, this doesn't seem to make a difference. By searching
the GitHub code base it doesn't look like this option is used
anywhere:
https://github.com/search?q=org%3ABioconductor+BIOCMANAGER_CRANCHECK_BEHAVIOR=Code
My current workaround it to not use BiocManager and roll my own
'repos' settings;
> unname(getOption("repos"))
[1] "https://cloud.r-project.org;
[2] "https://bioconductor.org/packages/3.10/bioc;
[3] "https://bioconductor.org/packages/3.10/data/annotation;
[4] "https://bioconductor.org/packages/3.10/data/experiment;
[5] "https://bioconductor.org/packages/3.10/workflows;
and use good old update.packages().
Alternative wish: It would be handy if there was a
BiocManager::repositories(version = "3.10") for finding these,
especially since some of them come and go depending on Bioc version.
/Henrik
PS. I also tried setting ditto env var because it looked more like an
env var than R option name to me.
>
> On Thu, Oct 31, 2019 at 2:21 PM Henrik Bengtsson
> wrote:
>>
>> (posting this here since I think it's not a support question per se)
>>
>> Hi, I just started an upgrade from Bioc 3.9 to 3.10 on my local R 3.6.1
>> setup:
>>
>> > BiocManager::install(version = "3.10")
>> Upgrade 73 packages to Bioconductor version '3.10'? [y/n]: y
>> Bioconductor version 3.10 (BiocManager 1.30.9), R 3.6.1 Patched (2019-09-12
>> r77183)
>> Installing package(s) 'BiocVersion'
>> ...
>> Installing package(s) 'base64enc', 'future', 'future.callr', 'listenv',
>> 'matrixStats', 'munsell', 'png', 'profmem', 'R.oo', 'rcmdcheck', 'scales',
>> 'affxparser', 'affy', 'affyio', 'AffymetrixDataTestFiles', 'annotate',
>> 'AnnotationDbi', 'AnnotationForge', 'aroma.light', 'Biobase', 'BiocCheck',
>> 'BiocGenerics', 'BiocParallel', 'BiocStyle', 'BiocVersion', 'biocViews',
>> 'Biostrings', 'BSgenome', 'CGHbase', 'CGHcall', 'cytolib', 'DelayedArray',
>> 'DNAcopy', 'edgeR', 'flowCore', 'flowViz', 'genefilter', 'GenomeInfoDb',
>> 'GenomeInfoDbData', 'GenomicAlignments', 'GenomicRanges', 'GO.db', 'graph',
>> 'GSEABase', 'IlluminaDataTestFiles', 'illuminaio', 'impute', 'IRanges',
>> 'limma', 'marray', 'ncdfFlow', 'oligo', 'oligoClasses', 'org.Hs.eg.db',
>> 'pdInfoBuilder', 'preprocessCore', 'QDNAseq', 'QDNAseq.hg19',
>> 'QDNAseq.mm10',
>> 'RBGL', 'Rgraphviz', 'Rhdf5lib', 'Rhtslib', 'RProtoBufLib', 'Rsamtools',
>> 'rtracklayer', 'S4Vectors', 'ShortRead', 'STROMA4', 'SummarizedExperiment',
>> 'XVector', 'zlibbioc'
>> trying URL 'https://cloud.r-project.org/src/contrib/base64enc_0.1-3.tar.gz'
>> Content type 'application/x-gzip' length 7833 bytes
>> ==
>> downloaded 7833 bytes
>>
>> trying URL 'https://cloud.r-project.org/src/contrib/future_1.14.0.tar.gz'
>> Content type 'application/x-gzip' length 294967 bytes (288 KB)
>> ==
>> downloaded 288 KB
>> ...
>>
>> It surprised me that BiocManager::install() will _downgrade_ to CRAN(*)
>> package versions, even if you have newer versions installed. For
>> instance, I've got base64enc 0.1.4 from
>> http://www.rforge.net/base64enc/, my own development version of future
>> 1.14.0-9000, and so on. Note that the prompt says nothing about
>> downgrading. Is this really wanted and is there a way to avoid this?
>>
>> (*) Will this also downgrade Bioc developers' Bioc packages?
>>
>> Thanks,
>>
>> Henrik
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>
>
> --
> James W. MacDonald, M.S.
> Biostatistician
> University of Washington
> Environmental and Occupational Health Sciences
> 4225 Roosevelt Way NE, # 100
> Seattle WA 98105-6099
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] BiocManager::install() downgrade installed packages
The main goal for BiocManager is to help end users ensure that their R/BioC
installation is consistent for the version of R that they are using. So by
definition, any packages that are outside the versions for a given R/BioC
installation should be up or down-graded to make the installation valid.
There are those of us who are l33t enough to mix'n'match packages and debug
errors that may then occur. But it's probably not a good idea to make it
easily hacked by naive users, allowing them to do things that might cause
problems.
Anyway, I believe doing
options("BIOCMANAGER_CRANCHECK_BEHAVIOR" = FALSE)
will stop BiocManager::install from changing any installed CRAN packages.
And it's suitably obscure to limit that to the cool kids who can find it.
On Thu, Oct 31, 2019 at 2:21 PM Henrik Bengtsson
wrote:
> (posting this here since I think it's not a support question per se)
>
> Hi, I just started an upgrade from Bioc 3.9 to 3.10 on my local R 3.6.1
> setup:
>
> > BiocManager::install(version = "3.10")
> Upgrade 73 packages to Bioconductor version '3.10'? [y/n]: y
> Bioconductor version 3.10 (BiocManager 1.30.9), R 3.6.1 Patched (2019-09-12
> r77183)
> Installing package(s) 'BiocVersion'
> ...
> Installing package(s) 'base64enc', 'future', 'future.callr', 'listenv',
> 'matrixStats', 'munsell', 'png', 'profmem', 'R.oo', 'rcmdcheck',
> 'scales',
> 'affxparser', 'affy', 'affyio', 'AffymetrixDataTestFiles', 'annotate',
> 'AnnotationDbi', 'AnnotationForge', 'aroma.light', 'Biobase',
> 'BiocCheck',
> 'BiocGenerics', 'BiocParallel', 'BiocStyle', 'BiocVersion', 'biocViews',
> 'Biostrings', 'BSgenome', 'CGHbase', 'CGHcall', 'cytolib',
> 'DelayedArray',
> 'DNAcopy', 'edgeR', 'flowCore', 'flowViz', 'genefilter', 'GenomeInfoDb',
> 'GenomeInfoDbData', 'GenomicAlignments', 'GenomicRanges', 'GO.db',
> 'graph',
> 'GSEABase', 'IlluminaDataTestFiles', 'illuminaio', 'impute', 'IRanges',
> 'limma', 'marray', 'ncdfFlow', 'oligo', 'oligoClasses', 'org.Hs.eg.db',
> 'pdInfoBuilder', 'preprocessCore', 'QDNAseq', 'QDNAseq.hg19',
> 'QDNAseq.mm10',
> 'RBGL', 'Rgraphviz', 'Rhdf5lib', 'Rhtslib', 'RProtoBufLib', 'Rsamtools',
> 'rtracklayer', 'S4Vectors', 'ShortRead', 'STROMA4',
> 'SummarizedExperiment',
> 'XVector', 'zlibbioc'
> trying URL 'https://cloud.r-project.org/src/contrib/base64enc_0.1-3.tar.gz
> '
> Content type 'application/x-gzip' length 7833 bytes
> ==
> downloaded 7833 bytes
>
> trying URL 'https://cloud.r-project.org/src/contrib/future_1.14.0.tar.gz'
> Content type 'application/x-gzip' length 294967 bytes (288 KB)
> ==
> downloaded 288 KB
> ...
>
> It surprised me that BiocManager::install() will _downgrade_ to CRAN(*)
> package versions, even if you have newer versions installed. For
> instance, I've got base64enc 0.1.4 from
> http://www.rforge.net/base64enc/, my own development version of future
> 1.14.0-9000, and so on. Note that the prompt says nothing about
> downgrading. Is this really wanted and is there a way to avoid this?
>
> (*) Will this also downgrade Bioc developers' Bioc packages?
>
> Thanks,
>
> Henrik
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
--
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099
[[alternative HTML version deleted]]
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] BiocManager::install() downgrade installed packages
(posting this here since I think it's not a support question per se) Hi, I just started an upgrade from Bioc 3.9 to 3.10 on my local R 3.6.1 setup: > BiocManager::install(version = "3.10") Upgrade 73 packages to Bioconductor version '3.10'? [y/n]: y Bioconductor version 3.10 (BiocManager 1.30.9), R 3.6.1 Patched (2019-09-12 r77183) Installing package(s) 'BiocVersion' ... Installing package(s) 'base64enc', 'future', 'future.callr', 'listenv', 'matrixStats', 'munsell', 'png', 'profmem', 'R.oo', 'rcmdcheck', 'scales', 'affxparser', 'affy', 'affyio', 'AffymetrixDataTestFiles', 'annotate', 'AnnotationDbi', 'AnnotationForge', 'aroma.light', 'Biobase', 'BiocCheck', 'BiocGenerics', 'BiocParallel', 'BiocStyle', 'BiocVersion', 'biocViews', 'Biostrings', 'BSgenome', 'CGHbase', 'CGHcall', 'cytolib', 'DelayedArray', 'DNAcopy', 'edgeR', 'flowCore', 'flowViz', 'genefilter', 'GenomeInfoDb', 'GenomeInfoDbData', 'GenomicAlignments', 'GenomicRanges', 'GO.db', 'graph', 'GSEABase', 'IlluminaDataTestFiles', 'illuminaio', 'impute', 'IRanges', 'limma', 'marray', 'ncdfFlow', 'oligo', 'oligoClasses', 'org.Hs.eg.db', 'pdInfoBuilder', 'preprocessCore', 'QDNAseq', 'QDNAseq.hg19', 'QDNAseq.mm10', 'RBGL', 'Rgraphviz', 'Rhdf5lib', 'Rhtslib', 'RProtoBufLib', 'Rsamtools', 'rtracklayer', 'S4Vectors', 'ShortRead', 'STROMA4', 'SummarizedExperiment', 'XVector', 'zlibbioc' trying URL 'https://cloud.r-project.org/src/contrib/base64enc_0.1-3.tar.gz' Content type 'application/x-gzip' length 7833 bytes == downloaded 7833 bytes trying URL 'https://cloud.r-project.org/src/contrib/future_1.14.0.tar.gz' Content type 'application/x-gzip' length 294967 bytes (288 KB) == downloaded 288 KB ... It surprised me that BiocManager::install() will _downgrade_ to CRAN(*) package versions, even if you have newer versions installed. For instance, I've got base64enc 0.1.4 from http://www.rforge.net/base64enc/, my own development version of future 1.14.0-9000, and so on. Note that the prompt says nothing about downgrading. Is this really wanted and is there a way to avoid this? (*) Will this also downgrade Bioc developers' Bioc packages? Thanks, Henrik ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
