Re: [Bioc-devel] GenomicFeatures and/or TxDb.Hsapiens.UCSC.hg19.knownGene issue: missing tibble

2020-04-27 Thread Martin Morgan
Thanks everyone for playing along!

The order of packages doesn't influence order of installation, otherwise the 
user would have to know the dependency graph (although I think we're starting 
to become intimately familiar with such graphs!)

Like Felix I'm also of the opinion that the source and binary dependency graphs 
become dissociated somehow, and the source packages are installed independently 
even though they have (indirect) dependencies.

I don’t think we should patch BiocManager; that's not where the problem is. 
Also, I wouldn't want to delegate such an important function to a third-party 
package, especially on CRAN where we do not have a 'devel' branch for things to 
run amuck if the implementation changes.

My guess would be the `dependencies = TRUE` Charlotte identifies creates a much 
more dense dependency graph (the important part is probably `Suggests`, 
recursively) that is more stable when only source packages are considered.

If you're interested...

The relevant code starts around here:

https://github.com/wch/r-source/blob/b86c46d25b12faa21bcc8828f1ff1ae3cb4f03e7/src/library/utils/R/packages2.R#L399

This is where the binary packages are installed:

https://github.com/wch/r-source/blob/b86c46d25b12faa21bcc8828f1ff1ae3cb4f03e7/src/library/utils/R/packages2.R#L492

...and the non-binary packages are identified:

https://github.com/wch/r-source/blob/b86c46d25b12faa21bcc8828f1ff1ae3cb4f03e7/src/library/utils/R/packages2.R#L509

I'm not sure whether these conditionals are evaluated, but could be important...

https://github.com/wch/r-source/blob/b86c46d25b12faa21bcc8828f1ff1ae3cb4f03e7/src/library/utils/R/packages2.R#L716

and finally shelling out(umph!) to install packages from source:

https://github.com/wch/r-source/blob/b86c46d25b12faa21bcc8828f1ff1ae3cb4f03e7/src/library/utils/R/packages2.R#L842

`install.packages()` is too complicated to `debug(install.packages)` and then 
step through; I've found it better to debug the function being called, e.g., 
`debug(system2)` and to build R from source with `browser()` or `print()` 
statements inserted -- the latter isn't so bad if building 'out of tree': patch 
the source then cd into bin/R-devel/src/library/utils and run make.

Martin

On 4/27/20, 5:09 PM, "Bioc-devel on behalf of Felix Ernst" 
 
wrote:

Hi,

Thanks for the discussion and the insight into possible solutions.

I currently have the same problem with settings up an RNAmodR GitHub 
Action. This fails because the RNAmodR requires RNAmodR.Data, which suggests 
GenomicRanges, which then leads to GenomeInfoDb and GenomeInfoDbData. What 
struck me was the fact, that GenomeInfoDbData is installed as a source package 
after RNAmodR.Data, which is basically the same situation as Leonardo describes 
for the TxDb packages.
So why is the package GenomeInfoDbData, which does not have any 
dependencies at all (except R) is not installed first? I tried to fix it by 
adding GenomeInfoDbData to the depends of RNAmodR. This solved the problem on 
macOS, but not on windows the tibble problem remains 
(https://github.com/FelixErnst/RNAmodR/runs/623569724). This makes sense, 
because tibble is currently available as binary for macOS, but not windows. 
Adding tibble will probably solve this as well, but that cannot be a permanent 
solution, can it?

I also have a question regarding the inner working of BiocManager::install: 
I used the following command to install dependencies: 
BiocManager::install(remotes::dev_package_deps(dependencies = TRUE, repos = 
c(BiocManager::repositories(),getOption('repos')))$package). Is the order in 
which the packages are given important?

To state a hypothesis: In both cases, GenomeInfoDbData and tibble, source 
packages are affected, which are required, by a binary package, which is then 
again required by a source package. Maybe this bridge by a binary package is 
not picked up, when trying to sort for the install order of the source packages.

Does this sound reasonable or is it there something I haven't thought 
about? Thanks for any advice.

Best regards,
Felix

-Ursprüngliche Nachricht-
Von: Bioc-devel  Im Auftrag von Leonardo 
Collado Torres
Gesendet: Montag, 27. April 2020 18:07
An: Charlotte Soneson 
Cc: Bioc-devel 
Betreff: Re: [Bioc-devel] GenomicFeatures and/or 
TxDb.Hsapiens.UCSC.hg19.knownGene issue: missing tibble

Hi,

I also ran more tests, which makes me think that the issue was with the 
list of dependencies we were asking `remotes` to install.


First, regarding the second to last email from Charlotte, the step-wise 
installation I did mostly using remotes was not ideal. I found a complicated 
scenario in another package that I contribute to where 
BSgenome.Hsapiens.UCSC.hg19 had to be downloaded twice (it failed the first 
time). That was `brainflowprobes` on Windows at


Re: [Bioc-devel] GenomicFeatures and/or TxDb.Hsapiens.UCSC.hg19.knownGene issue: missing tibble

2020-04-27 Thread Felix Ernst
Hi,

Thanks for the discussion and the insight into possible solutions.

I currently have the same problem with settings up an RNAmodR GitHub Action. 
This fails because the RNAmodR requires RNAmodR.Data, which suggests 
GenomicRanges, which then leads to GenomeInfoDb and GenomeInfoDbData. What 
struck me was the fact, that GenomeInfoDbData is installed as a source package 
after RNAmodR.Data, which is basically the same situation as Leonardo describes 
for the TxDb packages.
So why is the package GenomeInfoDbData, which does not have any dependencies at 
all (except R) is not installed first? I tried to fix it by adding 
GenomeInfoDbData to the depends of RNAmodR. This solved the problem on macOS, 
but not on windows the tibble problem remains 
(https://github.com/FelixErnst/RNAmodR/runs/623569724). This makes sense, 
because tibble is currently available as binary for macOS, but not windows. 
Adding tibble will probably solve this as well, but that cannot be a permanent 
solution, can it?

I also have a question regarding the inner working of BiocManager::install: I 
used the following command to install dependencies: 
BiocManager::install(remotes::dev_package_deps(dependencies = TRUE, repos = 
c(BiocManager::repositories(),getOption('repos')))$package). Is the order in 
which the packages are given important?

To state a hypothesis: In both cases, GenomeInfoDbData and tibble, source 
packages are affected, which are required, by a binary package, which is then 
again required by a source package. Maybe this bridge by a binary package is 
not picked up, when trying to sort for the install order of the source packages.

Does this sound reasonable or is it there something I haven't thought about? 
Thanks for any advice.

Best regards,
Felix

-Ursprüngliche Nachricht-
Von: Bioc-devel  Im Auftrag von Leonardo 
Collado Torres
Gesendet: Montag, 27. April 2020 18:07
An: Charlotte Soneson 
Cc: Bioc-devel 
Betreff: Re: [Bioc-devel] GenomicFeatures and/or 
TxDb.Hsapiens.UCSC.hg19.knownGene issue: missing tibble

Hi,

I also ran more tests, which makes me think that the issue was with the list of 
dependencies we were asking `remotes` to install.


First, regarding the second to last email from Charlotte, the step-wise 
installation I did mostly using remotes was not ideal. I found a complicated 
scenario in another package that I contribute to where 
BSgenome.Hsapiens.UCSC.hg19 had to be downloaded twice (it failed the first 
time). That was `brainflowprobes` on Windows at
https://github.com/LieberInstitute/brainflowprobes/runs/621460015?check_suite_focus=true#step:12:1142
and 
https://github.com/LieberInstitute/brainflowprobes/runs/621460015?check_suite_focus=true#step:12:1410.
Downloading such a big package (or any package) twice is really wasteful. So we 
can discard that path.


Secondly, I also found about remotes::local_package_deps() like Charlotte just 
mentioned prompted by Martin's question. As suggested by Martin, I'm now trying 
using BiocManager::install() only since it knows how to resolve Bioc's 
dependency tree. Thus my current GHA workflow uses BiocManager::install() with 
the "minimal" deps (the immediate dependencies). I still use 
remotes::dev_package_deps() to find which packages need to be updated in order 
to enable the caching functionality later on. I did this installation twice, 
just as a backup. Then I do a third BiocManager::install() call with any 
outdated packages across the full dependencies. That's what
https://github.com/leekgroup/derfinderPlot/blob/673608493488ae488ccb66e77e6deae5dabe69e0/.github/workflows/check-bioc.yml#L367-L393
does and here's the relevant code:


message(paste('', Sys.time(), 'installing BiocManager '))
remotes::install_cran("BiocManager")

## Pass #1 at installing dependencies
message(paste('', Sys.time(), 'pass number 1 at installing
dependencies: local dependencies ')) local_deps <- 
remotes::local_package_deps(dependencies = TRUE) deps <- 
remotes::dev_package_deps(dependencies = TRUE, repos =
BiocManager::repositories())
BiocManager::install(local_deps[local_deps %in% deps$package[deps$diff != 0]])

## Pass #2 at installing dependencies
message(paste('', Sys.time(), 'pass number 2 at installing
dependencies: local dependencies again ')) deps <- 
remotes::dev_package_deps(dependencies = TRUE, repos =
BiocManager::repositories())
BiocManager::install(local_deps[local_deps %in% deps$package[deps$diff != 0]])

## Pass #3 at installing dependencies
message(paste('', Sys.time(), 'pass number 3 at installing
dependencies: any remaining dependencies ')) deps <- 
remotes::dev_package_deps(dependencies = TRUE, repos =
BiocManager::repositories())
BiocManager::install(deps$package[deps$diff != 0])


For all 3 OS (Bioconductor devel docker, macOS, Windows) this works for 
`derfinderPlot`:
https://github.com/leekgroup/derfinderPlot/actions/runs/89153451.
Actually, in all 3, "pass #2" did nothing. Only in the docker one did 

[Bioc-devel] Bioconductor git repository commits have resumed

2020-04-27 Thread Nitesh Turaga

Dear Maintainers,

The commits to the Bioconductor repository have been resumed. The new 
branch RELEASE_3_11 has been created for all packages.


All maintainers should have access to the "master" (devel branch) and 
the RELEASE_3_11 branch of their packages.


Best regards,

Nitesh Turaga

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


[Bioc-devel] All commits to Bioconductor git repository frozen

2020-04-27 Thread Nitesh Turaga

Dear Maintainers,

As per my email about an hour ago, I've frozen the commits to 
Bioconductor git repository at 1:30pm EDT. Once we create the release 
3.11 branch, I will re-enable access.


The process will take about 2.5 - 3 hours.

Best,

Nitesh

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


[Bioc-devel] Fwd: Creating Bioconductor 3.11 branch on April 27th - 1:30PM EDT

2020-04-27 Thread Nitesh Turaga
Dear Maintainers,

Please keep in mind that we are on schedule for our release as given
in http://bioconductor.org/developers/release-schedule/
.

Today (April 27th 2020) at 1:30pm EDT, I will freeze the commits to
Bioconductor until further notice so we can create the RELEASE_3_11
branch for all packages (software, data experiment and workflow). The
process will take about 2.5 - 3 hours once commits are stopped.

Best regards,

Nitesh Turaga
Bioconductor Core Team

-- Forwarded message -
From: Nitesh Turaga 
Date: Mon, Apr 27, 2020 at 12:35 PM
Subject: Creating Bioconductor 3.11 branch on April 27th - 1:30PM EDT
To: Bioc-devel 


Dear Maintainers,

Please keep in mind that we are on schedule for our release as given
inhttp://bioconductor.org/developers/release-schedule/.

Today (April 27th 2020) at 1:30pm EDT, I willfreezethecommitsto
Bioconductor until further notice so we can create the RELEASE_3_11
branch for all packages (software, data experiment and workflow). The
process will take about 2.5 - 3 hours once commits are stopped.

Best regards,

Nitesh Turaga
Bioconductor Core Team

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


Re: [Bioc-devel] regutools: request to add more git push access

2020-04-27 Thread Carmina Barjon
Hi Nitesh! Yes, this it's the email address I will be using (
car.bar...@gmail.com).
Thank you
Carmina

El lun., 27 abr. 2020 a las 5:59, Nitesh Turaga ()
escribió:

> Hi Leo,
>
> I've added you and Alejandro to the regutools package.
>
> Carmina and Emiliano, please confirm the email addresses you'll be
> using. I can add you both as well, and create BiocCredentials accounts
> for you.
>
>
> Nitesh
>
> On 4/26/2020 11:42 PM, Leonardo Collado Torres wrote:
> > Hi Nitesh,
> >
> > Could you add me (l.collado-torres) and Alejandro Reyes (what's your
> > svn username Alejandro?) to regutools' list of contributors that have
> > git push access? I think this is what we are supposed to do from
> > re-reading
> https://github.com/Bioconductor/Contributions/issues/1393#issuecomment-597202057
> .
> >
> > Carmina & Emiliano might want git push access too, but they do not
> > have BioC git accounts as far as I know.
> >
> > Anyway, for now, I just wanted to add two commits already on GitHub
> > and push them to BioC's git repo following
> >
> http://bioconductor.org/developers/how-to/git/sync-existing-repositories/
> > before BioC 3.11's freeze.
> >
> > Thanks,
> > Leo
> >
> > ___
> > 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] Creating Bioconductor 3.11 branch on April 27th - 1:30PM EDT

2020-04-27 Thread Nitesh Turaga

Dear Maintainers,

Please keep in mind that we are on schedule for our release as given 
inhttp://bioconductor.org/developers/release-schedule/.


Today (April 27th 2020) at 1:30pm EDT, I willfreezethecommitsto 
Bioconductor until further notice so we can create the RELEASE_3_11 
branch for all packages (software, data experiment and workflow). The 
process will take about 2.5 - 3 hours once commits are stopped.


Best regards,

Nitesh Turaga
Bioconductor Core Team

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


Re: [Bioc-devel] Windows Development Build Error Message for COHCAP

2020-04-27 Thread Charles Warden
Hi,

I am not sure if I am going to have to wait to submit extra revisions.  
However, I am unfortunately having the same issue (even though I tested using 
the temporary directory instead of the current working directory, in COHCAP 
(v.1.33.4).

I also tested changing the file path to the temporary in v.1.33.6, but that 
also didn't fix the problem (and I might change that back).

I am also still not able to reproduce this error message on my end.

For example, this is what the output of the build command looks like:

C:\Users\Charles\Documents>"C:\Program Files\R\R-4.0.0\bin\R.exe" CMD build 
COHCAP
* checking for file 'COHCAP/DESCRIPTION' ... OK
* preparing 'COHCAP':
* checking DESCRIPTION meta-information ... OK
* cleaning src
* installing the package to build vignettes
* creating vignettes ... OK
* cleaning src
* checking for LF line-endings in source and make files and shell scripts
* checking for empty or unneeded directories
* building 'COHCAP_1.33.6.tar.gz'

And, I can also install COHCAP successfully using devtools (in R-4.0.0), 
although it does have some warnings:

> library("devtools")
Loading required package: usethis
> devtools::install_github("cwarden45/COHCAP")
Skipping install of 'COHCAP' from a github remote, the SHA1 (09b017ba) has not 
changed since last install.
  Use `force = TRUE` to force installation
> devtools::install_github("cwarden45/COHCAP", force=TRUE)
Downloading GitHub repo cwarden45/COHCAP@master
  
  
  
   checking for file 
'C:\Users\Charles\AppData\Local\Temp\RtmpOIc4WV\remotes370c11a9aa0\cwarden45-COHCAP-09b017b/DESCRIPTION'
 ...
  
   checking for file 
'C:\Users\Charles\AppData\Local\Temp\RtmpOIc4WV\remotes370c11a9aa0\cwarden45-COHCAP-09b017b/DESCRIPTION'
 ... 
  
√  checking for file 
'C:\Users\Charles\AppData\Local\Temp\RtmpOIc4WV\remotes370c11a9aa0\cwarden45-COHCAP-09b017b/DESCRIPTION'
 (339ms)

  
  
  
-  preparing 'COHCAP':
   checking DESCRIPTION meta-information ...
  
   checking DESCRIPTION meta-information ... 
  
√  checking DESCRIPTION meta-information
-  cleaning src

  
  
  
-  checking for LF line-endings in source and make files and shell scripts

  
  
  
-  checking for empty or unneeded directories

  
  
  
-  building 'COHCAP_1.33.6.tar.gz'

  
   

Installing package into ‘C:/Users/Charles/Documents/R/win-library/4.0’
(as ‘lib’ is unspecified)
* installing *source* package 'COHCAP' ...
** using staged installation
** libs
"C:/rtools40/mingw64/bin/"g++ -std=gnu++11  -I"C:/PROGRA~1/R/R-40~1.0/include" 
-DNDEBUG  -I'C:/Users/Charles/Documents/R/win-library/4.0/Rcpp/include' 
-I'C:/Users/Charles/Documents/R/win-library/4.0/BH/include'-O2 -Wall  
-mfpmath=sse -msse2 -mstackrealign -c RcppExports.cpp -o RcppExports.o
"C:/rtools40/mingw64/bin/"g++ -std=gnu++11  -I"C:/PROGRA~1/R/R-40~1.0/include" 
-DNDEBUG  -I'C:/Users/Charles/Documents/R/win-library/4.0/Rcpp/include' 
-I'C:/Users/Charles/Documents/R/win-library/4.0/BH/include'-O2 -Wall  
-mfpmath=sse -msse2 -mstackrealign -c Rcpp_BH_ANOVA.cpp -o Rcpp_BH_ANOVA.o
In file included from 
C:/Users/Charles/Documents/R/win-library/4.0/BH/include/boost/mpl/aux_/na_assert.hpp:23,
 from 
C:/Users/Charles/Documents/R/win-library/4.0/BH/include/boost/mpl/arg.hpp:25,
 from 
C:/Users/Charles/Documents/R/win-library/4.0/BH/include/boost/mpl/placeholders.hpp:24,
 from 
C:/Users/Charles/Documents/R/win-library/4.0/BH/include/boost/mpl/apply.hpp:24,
 from 
C:/Users/Charles/Documents/R/win-library/4.0/BH/include/boost/mpl/aux_/iter_apply.hpp:17,
 from 
C:/Users/Charles/Documents/R/win-library/4.0/BH/include/boost/mpl/aux_/find_if_pred.hpp:14,
 from 
C:/Users/Charles/Documents/R/win-library/4.0/BH/include/boost/mpl/find_if.hpp:17,
 from 
C:/Users/Charles/Documents/R/win-library/4.0/BH/include/boost/mpl/find.hpp:17,
 from 
C:/Users/Charles/Documents/R/win-library/4.0/BH/include/boost/mpl/aux_/contains_impl.hpp:20,
 from 
C:/Users/Charles/Documents/R/win-library/4.0/BH/include/boost/mpl/contains.hpp:20,
 from 
C:/Users/Charles/Documents/R/win-library/4.0/BH/include/boost/math/policies/policy.hpp:10,
 from 
C:/Users/Charles/Documents/R/win-library/4.0/BH/include/boost/math/special_functions/math_fwd.hpp:29,
 from 
C:/Users/Charles/Documents/R/win-library/4.0/BH/include/boost/math/special_functions/beta.hpp:13,
 from 
C:/Users/Charles/Documents/R/win-library/4.0/BH/include/boost/math/distributions/fisher_f.hpp:12,
 from Rcpp_BH_ANOVA.cpp:4:
C:/Users/Charles/Documents/R/win-library/4.0/BH/include/boost/mpl/assert.hpp:194:21:
 warning: unnecessary parentheses in declaration of 'assert_arg' [-Wparentheses]
 failed  (Pred::
 ^
C:/Users/Charles/Documents/R/win-library/4.0/BH/include/boost/mpl/assert.hpp:199:21:
 warning: unnecessary parentheses in 

Re: [Bioc-devel] regutools: request to add more git push access

2020-04-27 Thread Leonardo Collado Torres
Thank you Nitesh =)

And hm... I missed a couple of words in my email subject. Oops :P

On Mon, Apr 27, 2020 at 11:18 AM Carmina Barjon  wrote:
>
> Hi Nitesh! Yes, this it's the email address I will be using 
> (car.bar...@gmail.com).
> Thank you
> Carmina
>
> El lun., 27 abr. 2020 a las 5:59, Nitesh Turaga () 
> escribió:
>>
>> Hi Leo,
>>
>> I've added you and Alejandro to the regutools package.
>>
>> Carmina and Emiliano, please confirm the email addresses you'll be
>> using. I can add you both as well, and create BiocCredentials accounts
>> for you.
>>
>>
>> Nitesh
>>
>> On 4/26/2020 11:42 PM, Leonardo Collado Torres wrote:
>> > Hi Nitesh,
>> >
>> > Could you add me (l.collado-torres) and Alejandro Reyes (what's your
>> > svn username Alejandro?) to regutools' list of contributors that have
>> > git push access? I think this is what we are supposed to do from
>> > re-reading 
>> > https://github.com/Bioconductor/Contributions/issues/1393#issuecomment-597202057.
>> >
>> > Carmina & Emiliano might want git push access too, but they do not
>> > have BioC git accounts as far as I know.
>> >
>> > Anyway, for now, I just wanted to add two commits already on GitHub
>> > and push them to BioC's git repo following
>> > http://bioconductor.org/developers/how-to/git/sync-existing-repositories/
>> > before BioC 3.11's freeze.
>> >
>> > Thanks,
>> > Leo
>> >
>> > ___
>> > 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


Re: [Bioc-devel] GenomicFeatures and/or TxDb.Hsapiens.UCSC.hg19.knownGene issue: missing tibble

2020-04-27 Thread Leonardo Collado Torres
Hi,

I also ran more tests, which makes me think that the issue was with
the list of dependencies we were asking `remotes` to install.


First, regarding the second to last email from Charlotte, the
step-wise installation I did mostly using remotes was not ideal. I
found a complicated scenario in another package that I contribute to
where BSgenome.Hsapiens.UCSC.hg19 had to be downloaded twice (it
failed the first time). That was `brainflowprobes` on Windows at
https://github.com/LieberInstitute/brainflowprobes/runs/621460015?check_suite_focus=true#step:12:1142
and 
https://github.com/LieberInstitute/brainflowprobes/runs/621460015?check_suite_focus=true#step:12:1410.
Downloading such a big package (or any package) twice is really
wasteful. So we can discard that path.


Secondly, I also found about remotes::local_package_deps() like
Charlotte just mentioned prompted by Martin's question. As suggested
by Martin, I'm now trying using BiocManager::install() only since it
knows how to resolve Bioc's dependency tree. Thus my current GHA
workflow uses BiocManager::install() with the "minimal" deps (the
immediate dependencies). I still use remotes::dev_package_deps() to
find which packages need to be updated in order to enable the caching
functionality later on. I did this installation twice, just as a
backup. Then I do a third BiocManager::install() call with any
outdated packages across the full dependencies. That's what
https://github.com/leekgroup/derfinderPlot/blob/673608493488ae488ccb66e77e6deae5dabe69e0/.github/workflows/check-bioc.yml#L367-L393
does and here's the relevant code:


message(paste('', Sys.time(), 'installing BiocManager '))
remotes::install_cran("BiocManager")

## Pass #1 at installing dependencies
message(paste('', Sys.time(), 'pass number 1 at installing
dependencies: local dependencies '))
local_deps <- remotes::local_package_deps(dependencies = TRUE)
deps <- remotes::dev_package_deps(dependencies = TRUE, repos =
BiocManager::repositories())
BiocManager::install(local_deps[local_deps %in% deps$package[deps$diff != 0]])

## Pass #2 at installing dependencies
message(paste('', Sys.time(), 'pass number 2 at installing
dependencies: local dependencies again '))
deps <- remotes::dev_package_deps(dependencies = TRUE, repos =
BiocManager::repositories())
BiocManager::install(local_deps[local_deps %in% deps$package[deps$diff != 0]])

## Pass #3 at installing dependencies
message(paste('', Sys.time(), 'pass number 3 at installing
dependencies: any remaining dependencies '))
deps <- remotes::dev_package_deps(dependencies = TRUE, repos =
BiocManager::repositories())
BiocManager::install(deps$package[deps$diff != 0])


For all 3 OS (Bioconductor devel docker, macOS, Windows) this works
for `derfinderPlot`:
https://github.com/leekgroup/derfinderPlot/actions/runs/89153451.
Actually, in all 3, "pass #2" did nothing. Only in the docker one did
pass 3 do something (it updated `pkgbuild` which is not a direct
dependency of `derfinderPlot`).



If you like this, given that `BiocManager` already suggests `remotes`,
I could add a PR. Something like (with all the arguments and all
that):

bioc_dev_package_deps <- function() {

local_deps <- remotes::local_package_deps(dependencies = TRUE)
deps <- remotes::dev_package_deps(dependencies = TRUE, repos =
BiocManager::repositories())
BiocManager::install(local_deps[local_deps %in% deps$package[deps$diff != 0]])

}





Charlotte, in your small example, I saw that
https://github.com/csoneson/testinstall/commit/a5d7f473cad8fbaa4c7df8672dbdcf1994c0dd38
worked. Maybe it would still work with
BiocManager::install('TxDb.Hsapiens.UCSC.hg19.knownGene') only (the
minimal "deps" you found with Martin's code).

As for remotes::install_bioc() my understanding is that that function
ends up using the git Bioconductor versions. Double checking right
now, I see that the behavior depends on whether `git2r` is installed
https://github.com/r-lib/remotes/blob/master/R/install-bioc.R#L66.


Best,
Leo

PS If you update many packages at the same time with GHA, you can run
into timeout problems :P I was just trying to update my GHA workflow
on all my packages before the BioC 3.11 freeze.

PS2 Charlotte, I recommend that you set the GITHUB_PAT environment
variable 
https://github.com/leekgroup/derfinderPlot/blob/673608493488ae488ccb66e77e6deae5dabe69e0/.github/workflows/check-bioc.yml#L100.
Otherwise you depend on the one included in remotes and can run into
rate limiting issues. Though I actually ran into some even with it :P
https://github.com/LieberInstitute/recountWorkflow/runs/622552889?check_suite_focus=true#step:13:15
https://github.com/LieberInstitute/recountWorkflow/runs/622552889?check_suite_focus=true#step:13:20


On Mon, Apr 27, 2020 at 11:29 AM Charlotte Soneson
 wrote:
>
> Hi again,
>
> as for getting the immediate dependencies, this is what remotes does 
> internally (it includes also recommended packages though):
>
> deps <- 

Re: [Bioc-devel] GenomicFeatures and/or TxDb.Hsapiens.UCSC.hg19.knownGene issue: missing tibble

2020-04-27 Thread Charlotte Soneson
Hi again,

as for getting the immediate dependencies, this is what remotes does internally 
(it includes also recommended packages though):

deps <- remotes::local_package_deps(pkgdir = ".", dependencies = TRUE)

> I guess I would further simplify the problem by eliminating from 'deps' the 
> packages that do not contribute to the problem. So I wonder what a minimal 
> 'deps' looks like? This would be much more helpful for understanding the 
> problem than many 1000's of lines of output from CI.

For my small example package, deps (as created with your code below) was just 
TxDb.Hsapiens.UCSC.hg19.knownGene.

> So I conclude that the problem is actually IN BASE R, and that the fix is in 
> the incredibly complicated logic of install.packages.

I’m going to agree with this :) just to try to get a bit further, I went 
through the code of remotes, and in the end it comes down to calling 
install.packages() with a certain list of packages, and a specified set of 
repos (e.g. 
https://github.com/r-lib/remotes/blob/5b3da5f852772159cc2a580888e10536a43e9199/R/install.R#L75
 
).
 So I tried to just install some packages with install.packages(), in an empty 
library, to see what would happen. Experiments are here (not very easily 
accessible, I admit, but still) if someone is interested: 
https://github.com/csoneson/testinstall/actions 
 

Long story short, this works fine: 
> install.packages("TxDb.Hsapiens.UCSC.hg19.knownGene", repos = 
> c(getOption('repos'), BiocManager::repositories()), type = "both", 
> dependencies = TRUE)

This doesn’t (tries to install annotation packages before GenomeInfoDbData):
> install.packages(c("TxDb.Hsapiens.UCSC.hg19.knownGene","IRanges","GenomeInfoDb"),
>  repos = c(getOption('repos'), BiocManager::repositories()), type = "both", 
> dependencies = TRUE)
With other combinations of packages, sometimes it works, sometimes not. 

At the same time, this works fine:
> BiocManager::install(c("TxDb.Hsapiens.UCSC.hg19.knownGene","IRanges","GenomeInfoDb"))


And one more observation which may or may not be related: locally, this fails 
for me:

> remotes::install_bioc('TxDb.Hsapiens.UCSC.hg19.knownGene')

while this works: 

> remotes::install_bioc('SummarizedExperiment’)

Charlotte

> On 27 Apr 2020, at 12:11, Martin Morgan  wrote:
> 
> Personally, I wouldn't trust remotes to get the Bioconductor repositories, 
> and hence the dependency graph, correct. I say this mostly because of 
> problems to get BiocManager to get the repositories right during each phase 
> of the Biocoonductor release cycle, not to diss the remotes package.
> 
> I'd grab the immediate dependencies ONLY of the new package from the 
> DESCRIPTION file (does remotes have a function to do this? I'd trust it to do 
> a better job than my hack, but I'd double check it)
> 
>  dcf = read.dcf("DESCRIPTION", c("Depends", "Imports", "LinkingTo", 
> "Enhances", "Suggests"))
>  deps = unlist(strsplit(dcf, ",[[:space:]]*"))
>  deps = sub(" .*", "", deps)# no version info
>  deps = setdiff(deps, c("R", NA, rownames(installed.packages(priority = 
> "high"
> 
> I'd then do the builds with
> 
>  BiocManager::install(deps)
> 
> If that failed and I wanted to 'peel back' a layer of responsibility to get 
> closer to a minimal reproducible example, I'd do
> 
>  install.packages(deps, repos = BiocManager::repositories())
> 
> I believe that (maybe you can confirm?) this fails for your case. 
> 
> BiocManager::repositories() is just a named character vector -- in devel it 
> is currently
> 
>> dput(BiocManager::repositories())
>  c(BioCsoft = "https://bioconductor.org/packages/3.11/bioc;,
>BioCann =   "https://bioconductor.org/packages/3.11/data/annotation;,
>BioCexp = "https://bioconductor.org/packages/3.11/data/experiment;,
>BioCworkflows = "https://bioconductor.org/packages/3.11/workflows;,
>CRAN = "https://cran.rstudio.com;)
> 
> So I conclude that the problem is actually IN BASE R, and that the fix is in 
> the incredibly complicated logic of install.packages.
> 
> I guess I would further simplify the problem by eliminating from 'deps' the 
> packages that do not contribute to the problem. So I wonder what a minimal 
> 'deps' looks like? This would be much more helpful for understanding the 
> problem than many 1000's of lines of output from CI.
> 
> This might help to come up with a simple example to demonstrate Charlotte's 
> conclusion that the source packages are installed in the wrong order. And 
> that might also lead to a difference between parallel (options(Ncpus = 8), 
> for example) versus serial (options(Ncpus = NULL)) builds...
> 
> Thanks for your exhaustive work on this!
> 
> Martin
> 
> On 4/27/20, 2:03 AM, "Leonardo Collado Torres"  wrote:
> 
>EDIT:  I found a general solution! (workaround?) I had written a
>response, but I had 

Re: [Bioc-devel] No build report

2020-04-27 Thread Shepherd, Lori
It looks like you had merge conflicts with the version bump to 1.1.1  until 
late Sat night:

commit 199ad444e10c81c472deefe5dff5e32dff977b41
Author: Quy Xuan Cao 
Date:   Sat Apr 25 23:33:03 2020 -0400

Bump up to version 1.1.1 on github


This would be too late to be picked up on Sunday's build report but should be 
reflected in today's (normally posted sometime between 3-5PM EST).  If it isn't 
reflected in today's report, We (the core team)  are doing the freeze and bump 
and branch for the RELEASE_3_11 and it should resolve itself after that.

Cheers,



Lori Shepherd

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Cao, Quy 

Sent: Monday, April 27, 2020 10:15 AM
To: Nitesh Turaga ; Bioc-devel 

Subject: [Bioc-devel] No build report

Dear all,

I have pushed my updated package PERFect to Bioconductor last weekend but I 
haven't seen any build report yet. Is there something I can do in this 
situation?

Thanks,

Quy

-Original Message-
From: Bioc-devel  On Behalf Of Nitesh Turaga
Sent: Monday, April 27, 2020 9:00 AM
To: Leonardo Collado Torres ; Bioc-devel 

Cc: Carmina Barberena Jonas 
Subject: Re: [Bioc-devel] regutools: request to add more git push access

Hi Leo,

I've added you and Alejandro to the regutools package.

Carmina and Emiliano, please confirm the email addresses you'll be using. I can 
add you both as well, and create BiocCredentials accounts for you.


Nitesh

On 4/26/2020 11:42 PM, Leonardo Collado Torres wrote:
> Hi Nitesh,
>
> Could you add me (l.collado-torres) and Alejandro Reyes (what's your
> svn username Alejandro?) to regutools' list of contributors that have
> git push access? I think this is what we are supposed to do from
> re-reading 
> https://secure-web.cisco.com/1ss3pRMDsJo76mWIsyzXe9lDXoItH2sFabu1CE0znVtuQca1EmsAJSreHomRLs6G6xn_gOm6dFEx0dX7CnDzGwE4_uklxxTxCsGVOB_KCeo13s4UraPVR7afmm8_rnmkVrEWTGiTb3jvNrN_QDpXBQaMnWw2ymPtot2vNWY5mQp3d5vGiB0NhIRQnxoz7znJB70m6qEvbzJu1oIbjW5EkXrqiXt8ED0uwY1-b_L9vGSG6xw1MD3dFa2e6DuqHVr1fhCs4SFAGup5Ih2Ns9dFNEsoptDSjsEznRqTC8DIP4FHujFuZGPlFEcQXq37L_uE3_FlIEFSaT4zaqdX3r_cPnQ/https%3A%2F%2Fgithub.com%2FBioconductor%2FContributions%2Fissues%2F1393%23issuecomment-597202057.
>
> Carmina & Emiliano might want git push access too, but they do not
> have BioC git accounts as far as I know.
>
> Anyway, for now, I just wanted to add two commits already on GitHub
> and push them to BioC's git repo following
> http://secure-web.cisco.com/1cFasDB_kkp19Ri6C4NTgSGk39cBX_QF8Xn6DTqLzEL0ijtRrKn9gGLKXPGMHF0rrpS7AHZXUEHFchYfU-i08pRgke3QTkgyYR60jav1vUCef7Y_hfWdJr6A5EoeSXiE3GAXDGelk7GufWzF-PMrSGMVZIR19bEGVB2jmYRSCDg_Y3Bx2mhfjHjvOTuf8LldH6lSBbyW8MTvNOy9n9Ilybk5z-jUdXNyixRmRmuioLC0jmip-_8jinrjB1qPyFmIVPsy_vCLy_yPiZMsrsgK7TqeETN4FLwh0W0ey1uMCUDDrqdSgpLcdyxmKWXuvt6ZPa7PjgeUFJfPT-u8RRYzHgEcJ4K0T5K2GXZqmlChCMOo/http%3A%2F%2Fbioconductor.org%2Fdevelopers%2Fhow-to%2Fgit%2Fsync-existing-repositori
> es/
> before BioC 3.11's freeze.
>
> Thanks,
> Leo
>
> ___
> Bioc-devel@r-project.org mailing list
> https://secure-web.cisco.com/1FPy1mLnCRO4TAB6gES9DdpTKRi0nfju4Jo8fdrpIXLGRb6TToHLD_SrdXWMkprVgbO8wD0WP8jv0AMFq3SwEhj5qefE3vKBK6ty_SrnB38W89nw16Qnwpdl6rJJ_j-kAc-IBG15lXpt9ZGMltamh6dSEhN8kr74OiP2Eu8YkHa6qtt5KrH9mEAo8qqiKfrKunI9YBghKaNGwhpf1WnhkUwYwt3EI75Q98sMy91lhyEd1KtF5HUTY_-j2JBCugvhu4i2Ugx4B5578ISwRLAtUwpdIFGfuznPilVZmV-1BuTqkq8CfwNkks5x3obLruDxTJ0RjI4Nd6HbAu1Q7mT-3EQ/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel

___
Bioc-devel@r-project.org mailing list
https://secure-web.cisco.com/1FPy1mLnCRO4TAB6gES9DdpTKRi0nfju4Jo8fdrpIXLGRb6TToHLD_SrdXWMkprVgbO8wD0WP8jv0AMFq3SwEhj5qefE3vKBK6ty_SrnB38W89nw16Qnwpdl6rJJ_j-kAc-IBG15lXpt9ZGMltamh6dSEhN8kr74OiP2Eu8YkHa6qtt5KrH9mEAo8qqiKfrKunI9YBghKaNGwhpf1WnhkUwYwt3EI75Q98sMy91lhyEd1KtF5HUTY_-j2JBCugvhu4i2Ugx4B5578ISwRLAtUwpdIFGfuznPilVZmV-1BuTqkq8CfwNkks5x3obLruDxTJ0RjI4Nd6HbAu1Q7mT-3EQ/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel

___
Bioc-devel@r-project.org mailing list
https://secure-web.cisco.com/1FPy1mLnCRO4TAB6gES9DdpTKRi0nfju4Jo8fdrpIXLGRb6TToHLD_SrdXWMkprVgbO8wD0WP8jv0AMFq3SwEhj5qefE3vKBK6ty_SrnB38W89nw16Qnwpdl6rJJ_j-kAc-IBG15lXpt9ZGMltamh6dSEhN8kr74OiP2Eu8YkHa6qtt5KrH9mEAo8qqiKfrKunI9YBghKaNGwhpf1WnhkUwYwt3EI75Q98sMy91lhyEd1KtF5HUTY_-j2JBCugvhu4i2Ugx4B5578ISwRLAtUwpdIFGfuznPilVZmV-1BuTqkq8CfwNkks5x3obLruDxTJ0RjI4Nd6HbAu1Q7mT-3EQ/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel



This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or 

[Bioc-devel] No build report

2020-04-27 Thread Cao, Quy
Dear all,

I have pushed my updated package PERFect to Bioconductor last weekend but I 
haven't seen any build report yet. Is there something I can do in this 
situation?

Thanks,

Quy

-Original Message-
From: Bioc-devel  On Behalf Of Nitesh Turaga
Sent: Monday, April 27, 2020 9:00 AM
To: Leonardo Collado Torres ; Bioc-devel 

Cc: Carmina Barberena Jonas 
Subject: Re: [Bioc-devel] regutools: request to add more git push access

Hi Leo,

I've added you and Alejandro to the regutools package.

Carmina and Emiliano, please confirm the email addresses you'll be using. I can 
add you both as well, and create BiocCredentials accounts for you.


Nitesh

On 4/26/2020 11:42 PM, Leonardo Collado Torres wrote:
> Hi Nitesh,
>
> Could you add me (l.collado-torres) and Alejandro Reyes (what's your 
> svn username Alejandro?) to regutools' list of contributors that have 
> git push access? I think this is what we are supposed to do from 
> re-reading 
> https://github.com/Bioconductor/Contributions/issues/1393#issuecomment-597202057.
>
> Carmina & Emiliano might want git push access too, but they do not 
> have BioC git accounts as far as I know.
>
> Anyway, for now, I just wanted to add two commits already on GitHub 
> and push them to BioC's git repo following 
> http://bioconductor.org/developers/how-to/git/sync-existing-repositori
> es/
> before BioC 3.11's freeze.
>
> Thanks,
> Leo
>
> ___
> 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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


Re: [Bioc-devel] regutools: request to add more git push access

2020-04-27 Thread Nitesh Turaga

Hi Leo,

I've added you and Alejandro to the regutools package.

Carmina and Emiliano, please confirm the email addresses you'll be 
using. I can add you both as well, and create BiocCredentials accounts 
for you.



Nitesh

On 4/26/2020 11:42 PM, Leonardo Collado Torres wrote:

Hi Nitesh,

Could you add me (l.collado-torres) and Alejandro Reyes (what's your
svn username Alejandro?) to regutools' list of contributors that have
git push access? I think this is what we are supposed to do from
re-reading 
https://github.com/Bioconductor/Contributions/issues/1393#issuecomment-597202057.

Carmina & Emiliano might want git push access too, but they do not
have BioC git accounts as far as I know.

Anyway, for now, I just wanted to add two commits already on GitHub
and push them to BioC's git repo following
http://bioconductor.org/developers/how-to/git/sync-existing-repositories/
before BioC 3.11's freeze.

Thanks,
Leo

___
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


Re: [Bioc-devel] GenomicFeatures and/or TxDb.Hsapiens.UCSC.hg19.knownGene issue: missing tibble

2020-04-27 Thread Martin Morgan
Personally, I wouldn't trust remotes to get the Bioconductor repositories, and 
hence the dependency graph, correct. I say this mostly because of problems to 
get BiocManager to get the repositories right during each phase of the 
Biocoonductor release cycle, not to diss the remotes package.

I'd grab the immediate dependencies ONLY of the new package from the 
DESCRIPTION file (does remotes have a function to do this? I'd trust it to do a 
better job than my hack, but I'd double check it)

  dcf = read.dcf("DESCRIPTION", c("Depends", "Imports", "LinkingTo", 
"Enhances", "Suggests"))
  deps = unlist(strsplit(dcf, ",[[:space:]]*"))
  deps = sub(" .*", "", deps)# no version info
  deps = setdiff(deps, c("R", NA, rownames(installed.packages(priority = 
"high"

I'd then do the builds with

  BiocManager::install(deps)

If that failed and I wanted to 'peel back' a layer of responsibility to get 
closer to a minimal reproducible example, I'd do

  install.packages(deps, repos = BiocManager::repositories())

I believe that (maybe you can confirm?) this fails for your case. 

BiocManager::repositories() is just a named character vector -- in devel it is 
currently

  > dput(BiocManager::repositories())
  c(BioCsoft = "https://bioconductor.org/packages/3.11/bioc;,
BioCann =   "https://bioconductor.org/packages/3.11/data/annotation;,
BioCexp = "https://bioconductor.org/packages/3.11/data/experiment;,
BioCworkflows = "https://bioconductor.org/packages/3.11/workflows;,
CRAN = "https://cran.rstudio.com;)

So I conclude that the problem is actually IN BASE R, and that the fix is in 
the incredibly complicated logic of install.packages.

I guess I would further simplify the problem by eliminating from 'deps' the 
packages that do not contribute to the problem. So I wonder what a minimal 
'deps' looks like? This would be much more helpful for understanding the 
problem than many 1000's of lines of output from CI.

This might help to come up with a simple example to demonstrate Charlotte's 
conclusion that the source packages are installed in the wrong order. And that 
might also lead to a difference between parallel (options(Ncpus = 8), for 
example) versus serial (options(Ncpus = NULL)) builds...

Thanks for your exhaustive work on this!

Martin

On 4/27/20, 2:03 AM, "Leonardo Collado Torres"  wrote:

EDIT:  I found a general solution! (workaround?) I had written a
response, but I had an idea, tested it and a few hours later I'm
finishing this email. It does work... although not exactly as I
intended it to.



---

Thanks Martin for looking into this =)

I'll respond to your question about making things complicated for myself.


## General scenario

The general scenario is, I have a package say `newpkg`. `newpkg` has
dependencies (imports, suggests and/or depends) on Bioconductor
packages. I want to test that `newpkg` passes R CMD build, check &
BiocCheck. To do so, we need all the dependencies of `newpkg`
available including the "suggests" ones.

If `newpkg` was already available from Bioconductor, I could install
it using BiocManager::install("newpkg"). But that's not necessarily
the case.**

One could install the dependencies for `newpkg` manually, using
BiocManager::install(), remotes, and/or install.packages(). But then,
you need to adapt the code again for `newerpkg`, `oldpkg`, etc.

Currently, either through remotes::install_deps() or through
remotes::dev_package_deps(dependencies = TRUE) directly (the first
calls the second

https://github.com/r-lib/remotes/blob/5b3da5f852772159cc2a580888e10536a43e9199/R/install.R#L193)
Charlotte and I are getting the list of packages that `newpkg` depends
on, then either installing them through remotes or BiocManager. This
is failing for both of us, though in theory (as far as I know) either
should work. Is this something that could be fixed? I don't know.++


## GitHub Actions

Ultimately in my case, I'm trying to build a GitHub Actions workflow
that will work for any package with Bioconductor dependencies. I'm
nearly there, it's just this last issue about the source-only BioC
packages (annotation, experiment, workflow). I've been doing this
since last week and through this process I discovered some issues with
my own packages that were masked in the Bioconductor build machines.
Many other packages are already installed in the Bioconductor build
machines and on my laptop, so I hadn't noticed some missing "suggests"
dependencies on some of my packages. For example

https://github.com/leekgroup/recount/commit/f3bdb77d789f1a8364f16b71bd344fd23ecbfda5.


## Some possibilities to explore

Maybe what we need is some other code to process the DESCRIPTION file
of `newpkg`, extract the list of packages explicitly mentioned on
DESCRIPTION (removing those that are base packages, say 

Re: [Bioc-devel] Question about "Warning: '.local' is deprecated."

2020-04-27 Thread Jakob Theorell
Thank you!
Found it: "flowCore::description" is old, "flowCore::keyword" is replacement.
Best regards
Jakob

From: Martin Morgan 
Sent: 27 April 2020 10:28
To: Jakob Theorell ; bioc-devel@r-project.org 

Subject: Re: [Bioc-devel] Question about "Warning: '.local' is deprecated."

I would suggest forcing warnings to errors

options(warn=2)

and then when the now-error occurs using

traceback()

to see what is wrong -- I think this is a call to a deprecated S4 method, and 
what you'd really like is the method signature.

Martin

On 4/27/20, 2:58 AM, "Bioc-devel on behalf of Jakob Theorell" 
 
wrote:

Dear all,
In one of my packages, flowSpecs, I have over the last weeks gotten this 
warning message:


* checking examples ... WARNING
Found the following significant warnings:

  Warning: '.local' is deprecated.
Deprecated functions may be defunct as soon as of the next release of
R.
See ?Deprecated.

I am trying my best to check the ?Deprecated pages, but I find them quite 
uninformative, and the specific deprecation help does not take me further 
either, it only says:

> .Deprecated(old = ".local")
Warning message:
'.local' is deprecated.
See help("Deprecated")

And most annoying of all: there are no .local calls in the package since 
weeks back. Very thankful for any input that can straighten this out.
Best regards

Jakob Theorell, MD/PhD
Autoimmune Neurology Group
Nuffield Department of Clinical Neurosciences
University of Oxford
Phone: +447597976151





 [[alternative HTML version deleted]]

___
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


Re: [Bioc-devel] GenomicFeatures and/or TxDb.Hsapiens.UCSC.hg19.knownGene issue: missing tibble

2020-04-27 Thread Charlotte Soneson
Thanks both, this is very informative!

It seems to me (at least from my small example) that what causes the actual 
installation failure is not the “binary-before-source” installation (as Martin 
said, this would not fail since the binaries are not loaded), but that the 
source packages are installed in the wrong order. For example, in my test 
package the actual dependency (the TxDb package) is installed first (before the 
other source packages, which it needs): 

https://github.com/csoneson/testpkg/runs/619407291?check_suite_focus=true#step:7:514
 

The downloaded binary packages are in
C:\Users\runneradmin\AppData\Local\Temp\RtmpqM7M39\downloaded_packages
installing the source packages 'TxDb.Hsapiens.UCSC.hg19.knownGene', 
'GenomeInfoDbData', 'tibble'

I’m not sure that this is transient (sorry if I misunderstood you Martin) - if 
you depend on a source-only package that depends on another source-only package 
like in this case, it seems that the above will currently go wrong every time. 

Leo, I find your stepwise approach interesting. I wonder if there would still 
be an issue if you, say, depend on a source-later-than-binary CRAN package that 
in turn depends on another source-later-than-binary CRAN package (that is, if 
the second step in your installation would get the order right or wrong in such 
a case). Or, say, if GenomeInfoDbData would depend on tibble, would they be 
installed in the right order (they are both installed in the CRAN step)? 

In any case, my own conclusion is that I need to go back and understand better 
how all these things really are determined. For example, in Martin’s example 
below I would wonder what would be the order if it was “bar” that had a newer 
source version, or if both “baz” and “bar” had newer source versions, or if the 
dependency chain there was different…basically, why are the source packages 
above installed in that particular order. 

Thanks!
Charlotte 

> On 27 Apr 2020, at 08:02, Leonardo Collado Torres  
> wrote:
> 
> EDIT:  I found a general solution! (workaround?) I had written a
> response, but I had an idea, tested it and a few hours later I'm
> finishing this email. It does work... although not exactly as I
> intended it to.
> 
> 
> 
> ---
> 
> Thanks Martin for looking into this =)
> 
> I'll respond to your question about making things complicated for myself.
> 
> 
> ## General scenario
> 
> The general scenario is, I have a package say `newpkg`. `newpkg` has
> dependencies (imports, suggests and/or depends) on Bioconductor
> packages. I want to test that `newpkg` passes R CMD build, check &
> BiocCheck. To do so, we need all the dependencies of `newpkg`
> available including the "suggests" ones.
> 
> If `newpkg` was already available from Bioconductor, I could install
> it using BiocManager::install("newpkg"). But that's not necessarily
> the case.**
> 
> One could install the dependencies for `newpkg` manually, using
> BiocManager::install(), remotes, and/or install.packages(). But then,
> you need to adapt the code again for `newerpkg`, `oldpkg`, etc.
> 
> Currently, either through remotes::install_deps() or through
> remotes::dev_package_deps(dependencies = TRUE) directly (the first
> calls the second
> https://github.com/r-lib/remotes/blob/5b3da5f852772159cc2a580888e10536a43e9199/R/install.R#L193)
> Charlotte and I are getting the list of packages that `newpkg` depends
> on, then either installing them through remotes or BiocManager. This
> is failing for both of us, though in theory (as far as I know) either
> should work. Is this something that could be fixed? I don't know.++
> 
> 
> ## GitHub Actions
> 
> Ultimately in my case, I'm trying to build a GitHub Actions workflow
> that will work for any package with Bioconductor dependencies. I'm
> nearly there, it's just this last issue about the source-only BioC
> packages (annotation, experiment, workflow). I've been doing this
> since last week and through this process I discovered some issues with
> my own packages that were masked in the Bioconductor build machines.
> Many other packages are already installed in the Bioconductor build
> machines and on my laptop, so I hadn't noticed some missing "suggests"
> dependencies on some of my packages. For example
> https://github.com/leekgroup/recount/commit/f3bdb77d789f1a8364f16b71bd344fd23ecbfda5.
> 
> 
> ## Some possibilities to explore
> 
> Maybe what we need is some other code to process the DESCRIPTION file
> of `newpkg`, extract the list of packages explicitly mentioned on
> DESCRIPTION (removing those that are base packages, say it's 10
> packages), then just install those direct dependencies (the 10
> packages) instead of all the packages listed in the DESCRIPTION and
> their dependencies (what you can get from remotes::dev_package_deps(),
> say 100 packages) and pass this smaller list of direct dependencies to
> BiocManager::install().