[Bioc-devel] TREG git push request access
Hi bioc-devel, Similar to my qsvaR email, can you give me git access to TREG? Louise is still the primary maintainer, but I'm helping her here and there. Thanks, Leo Leonardo Collado Torres, Ph. D. Investigator LIEBER INSTITUTE for BRAIN DEVELOPMENT 855 N. Wolfe St., Suite 300 Baltimore, MD 21205 lcolladotor.github.io lcollado...@gmail.com ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] qsvaR git access update request
Hi BioC-devel, Could you give access to Hédia Tnani (https://github.com/HediaTnani from my team) and myself to push updates to qsvaR? Joshua M. Stolz is no longer working at LIBD and is no longer maintaining qsvaR. Hédia will take over maintenance duties, though I'll help her here and there. Hédia, from https://contributions.bioconductor.org/git-version-control.html?q=DENIED%20by%20fallthru#faq you'll need to submit your information to https://git.bioconductor.org/BiocCredentials/. Thanks, Leo Leonardo Collado Torres, Ph. D. Investigator LIEBER INSTITUTE for BRAIN DEVELOPMENT 855 N. Wolfe St., Suite 300 Baltimore, MD 21205 lcolladotor.github.io lcollado...@gmail.com ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] Bioconductor Technical Advisory Board Nominations Open
Do you want to join the Bioconductor Technical Advisory Board, or do you know someone who would be a great fit? Then fill this short form (if you're nominating someone else, please first confirm that they are interested) before May 31 (at midnight in a time zone of your choice): https://forms.gle/X3sq7RJxic3t4dBT8. If you are unable to access Google Forms, please see this pdf of questions: https://bioconductor.org/about/technical-advisory-board/tab-nomination-form-2023.pdf, and email your answers to charlottesoneson (at) gmail.com. For more information about the current board and the election process, see https://bioconductor.org/about/technical-advisory-board/, and if you have questions, feel free to post them in the #tech-advisory-board channel in the Bioconductor slack workspace (join at https://slack.bioconductor.org/). Please help spread the word! Charlotte, on behalf of the Bioconductor Technical Advisory Board ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
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 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
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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] TCGAbiolinks fails
Hello, Sorry for the late reply, I will fix the package this week. I will also need to do a major change in the code since GDC legacy will be shut down in the next months. Best regards, Tiago Chedraoui Silva On Fri, Apr 28, 2023 at 10:04 AM Dario Strbenac via Bioc-devel < bioc-devel@r-project.org> wrote: > Good day, > > The package has checking errors which the developers of it need to fix > themselves. > > Quitting from lines 114-121 (subtypes.Rmd) > Error: processing vignette 'subtypes.Rmd' failed with diagnostics: > object 'lgg.gbm.subtype' not found > > The installation error simply indicates that the package has never built > successfully in Bioconductor 3.17. > > -- > Dario Strbenac > University of Sydney > Camperdown NSW 2050 > Australia > ___ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[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
