Question: Cannot install flowViz package because dependency flowCore cannot be found, however flowCore has just been installed.
1
8 months ago by
ghn87610
ghn87610 wrote:

I am trying to install the flowViz package and it is saying that the dependency flowCore is not available even though it has just installed it.

I created a new directory, set the .libPaths() to point only to there and then called

source("https://bioconductor.org/biocLite.R")
biocLite("flowViz")

in the usual fashion. This installs all of the necessary dependencies - including flowCore - and then when it gets to flowViz itself it says flowCore is not found. The tail end of the output is below:

** R
** data
** inst
** help
*** installing help indices
** building package indices
** installing vignettes
** testing if installed package can be loaded
* DONE (flowCore)
* installing *source* package ‘flowViz’ ...
** R
** inst
** help
*** installing help indices
** building package indices
** installing vignettes
** testing if installed package can be loaded
Error : package ‘flowCore’ required by ‘flowViz’ could not be found
Execution halted
* removing ‘/home/Foo/Bar/flowViz’

The downloaded source packages are in
Warning message:
In install.packages(pkgs = doing, lib = lib, ...) :
installation of package ‘flowViz’ had non-zero exit status
Calls: biocLite ... .biocLiteInstall -> .reposInstall -> install.packages

I can even load flowCore after that:

>
> library(flowCore)
>
> sessionInfo()
R version 3.5.1 (2018-07-02)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.5 LTS

Matrix products: default
BLAS: /Foo/R-3.5.1/lib/R/lib/libRblas.so
LAPACK: /Foo/R-3.5.1/lib/R/lib/libRlapack.so

locale:
[1] LC_CTYPE=en_NZ.UTF-8       LC_NUMERIC=C               LC_TIME=en_NZ.UTF-8        LC_COLLATE=en_NZ.UTF-8     LC_MONETARY=en_NZ.UTF-8
[6] LC_MESSAGES=en_NZ.UTF-8    LC_PAPER=en_NZ.UTF-8       LC_NAME=C                  LC_ADDRESS=C               LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_NZ.UTF-8 LC_IDENTIFICATION=C       
attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     
other attached packages:
[1] flowCore_1.46.1      BiocInstaller_1.30.0 prettycode_1.0.1    
loaded via a namespace (and not attached):
[1] Rcpp_0.12.18        mvtnorm_1.0-8       lattice_0.20-35     matrixStats_0.54.0  corpcor_1.6.9       digest_0.6.16       crayon_1.3.4
[8] withr_2.1.2         rrcov_1.4-4         grid_3.5.1          pcaPP_1.9-73        stats4_3.5.1        graph_1.58.0        robustbase_0.93-2
[15] devtools_1.13.6     tools_3.5.1         Biobase_2.40.0      DEoptimR_1.0-8      parallel_3.5.1      compiler_3.5.1      BiocGenerics_0.26.0
[22] cluster_2.0.7-1     memoise_1.1.0    

And yet flowViz still says it cannot be found.

I have recently upgraded to R 3.5.1 and I suspect the error is related to this rather than Bioconductor, however I haven't found any CRAN packages that produce a similar error.

I got the same results trying to install RBGL from Bioconductor where it installed the graph package and then said RBGL can't be installed because graph cannot be found.

I'm using Bioconductor 3.7.

Any help would be much appreciated,

Cheers

modified 8 months ago by Martin Morgan ♦♦ 23k • written 8 months ago by ghn87610
Answer: Cannot install flowViz package because dependency flowCore cannot be found, howe
0
8 months ago by
Martin Morgan ♦♦ 23k
United States
Martin Morgan ♦♦ 23k wrote:

I think that .libPaths() has more than one entry, and that flowCore is installed in, e.g., the second entry. Try removing flowCore from all locations, and installing it again. Then try to install flowViz.

When I start up R I type .libPaths('.') to set it to point only to my temp directory I am using to test the installation. If I then call .libPaths() it has the first entry as the current temp directory and the second as the location of the base and recommended R packages "R-3.5.1/lib/R/library", i.e. base, boot, class, cluster, etc.

If I do find.package('flowCore') it returns the location of the temp directory I just installed into. After deleting that copy find.package fails to locate anything (and library(flowCore) fails).

I then installed flowCore again and flowViz and ended up with the same error described above.

try BiocManager::install("flowViz") from the fresh-started R session and paste the entire error message if still fails.

As a work-around I think you can also BiocInstaller::biocLite("flowViz", INSTALL_args="--no-test-load").

It would also be helpful to know if the underlying R functionality is the culprit, i.e., if before the workaround install.packages("flowViz", repos=BiocInstaller::biocinstallRepos()) works.

(Typed this before I saw the last two replies - thanks to both of you)

I have found a workaround but I believe there is a genuine issue here.

The way we have R set up is that there is directory created to install Bioconductor packages into, /opt/apps/x86_64/R/Bioconductor, and this is pointed to by an Renviron.site file that has been added to the etc directory of the R installation (/opt/apps/x86_64/R/R-3.5.1/lib/R/etc).

This Renviron.site file contains the line:
R_LIBS=/opt/apps/x86_64/R/Bioconductor

Individual users can then pre-pend a local libPath if they desire using .Renviron file in their home directory, as per the startup documentation of R.

I wanted to test a Bioconductor package without interfering with the shared Bioconductor directory which is why I created a temp directory to try installing flowViz into.

So I created a temp directory and set .libPaths('.') to cut out the shared location "/opt/apps/x86_64/R/Bioconductor" and then called biocLite('flowViz') as described above. This downloaded flowCore and flowViz (and others) and installed them into the temp directory, eventually failing at flowViz. However if I go back and install flowCore into the shared location and try again I can then successfully install flowViz into my temp directory - without changing libPaths.

So what happens, as far as I can tell, is that when I call biocLite('flowViz') it uses the libPaths pointing to my temp directory to determine what packages to download for installation but when it gets to the line "testing if installed package can be loaded" it resets to the default libPaths that one gets on startup.

Is there a system call somewhere that is failing to pass along the correct libPaths?

It is probably not a common use case but it does seem odd.