Installation instructions are very much incomplete

[pcarbo]

When I try to install pecotmr, I get this error:

ERROR: dependencies ‘mr.ash.alpha’, ‘mr.mash.alpha’, ‘udr’, ‘snpStats’, ‘fsusieR’, ‘mvsusieR’, ‘qvalue’ 
are not available for package ‘pecotmr’

These packages are not available on CRAN which is why the installation fails. I would recommend using the Remotes: in DESCRIPTION to tell remotes::install_github where to find these packages. See here for an illustration, and see here for details.

Once you have updated your DESCRIPTION I can check that it works.

Unrelated, I got a second installation error that is due to some installation difficulties with Rfast. I eventually got it working, but I'll note that the system requirements are quite stringent — Rfast will be quite difficult to install for many people. If you can make it an optional depenency, that would help a lot.

[kevinlkx]

I got an installation error using micromamba install r-pecotmr -c dnachun

error    libmamba Could not solve for environment specs
    The following package could not be installed
    └─ r-pecotmr is not installable because it requires
       └─ bioconductor-iranges >=2.36.0,<2.37.0a0, which does not exist (perhaps a missing channel).
critical libmamba Could not solve for environment specs

[danielnachun]

Thanks for noting these issues.

qvalue and snpstats are Bioconductor packages so I need to see how to make sure that these get pulled from there correctly.

We are no longer using udr, so that should be removed.

mr.ash.alpha, mr.mash.alpha, fsusieR and mvsusieR should all be handled with remotes as you described. We hoping these packages can all be submitted to CRAN in the near-ish future (we're happy to try to help with that!).

@kevinlkx I believe this is because it should be micromamba install r-pecotmr -c dnachun -c conda-forge -c bioconda and I see our instructions for this are incorrect, so I will fix that too.

[danielnachun]

@pcarbo Can you also share the failure you experienced with Rfast? I think this can be made optional as we are using for faster LD calculation (though it makes a big difference). I'm guessing it needs a newer C++ compiler, and in the era of conda-forge this is actually quite easy to provide instructions for.

[danielnachun]

These issues should be fixed by #271 and #272

[pcarbo]

Can you also share the failure you experienced with Rfast?

This is the issue with Rfast:

SystemRequirements: C++17

CRAN strongly discourages such requirements because it many platforms by default do not support this requirement (that is, with standard system compilers).

So my suggestion is to make it a "suggested" package, and add a strongly worded message if it is not being used to encourage people to install it (noting that computations can be very slow if it is not used). This is the approach we have taken in other packages such as susieR.

[pcarbo]

@danielnachun Your new installation instructions aren't working for me:

> BiocManager::install("cumc/pecotmr",update=FALSE,ask=FALSE)
ERROR: dependencies ‘mr.ash.alpha’, ‘mr.mash.alpha’, ‘fsusieR’, ‘mvsusieR’ are not available for package ‘pecotmr’

[danielnachun]

I wasn't able to test this before in a totally clean system but now that I have I found a few different issues with the full source build. I'm working on the fixes now - not only did I specify the Remotes: section incorrectly, but we also have some suggested packages that are currently not actually optional.

I'll work on making more packages optional or removing some dependencies all together:

• I think we're dropping udr entirely
• magrittr will be replaced with the native R pipe
• data.table will be replaced with vroom/dplyr/readr
• All of the externally implemented penalized regression methods should probably be optional, so the user can choose which weighting methods they want to use other than SuSiE for TWAS
• There's some omnibus testing stuff from GBJm harmonicmeanp and SKAT that should be optional
• The quantile QTL dependencies can probably be optional, and this may even end up in a different package
• The packages for supporting different kinds of genotype data (plink .bed/.bim/.fam, plink2 .pgen/.pvar/.psam, VCF, and GDS) might be optional so the user can just install the ones they need

[danielnachun]

@pcarbo I've now gotten everything to fully build from source using BiocManager, so please give it a try again. Once we've pruned the dependency tree better and the development cycle of this package isn't as fast I will enable testing of full source builds for Linux in our CI pipeline. For macOS I'm going to assume anyone installing it is using the official R.app distribution that uses binary packages. Windows support testing is the lowest priority but will still eventually be added to the CI pipeline, under the same assumption as macOS that the user is getting binary packages when possible.

[pcarbo]

Thanks @danielnachun. I haven't fully checked that the installation works on my end, but it does look greatly improved.

[mumdark]

I'm having the same problem.

> install.packages("Rfast")
Installing package into ‘/home/liudefu/R/x86_64-pc-linux-gnu-library/4.1’
(as ‘lib’ is unspecified)
trying URL 'https://mirrors.e-ducation.cn/CRAN/src/contrib/Rfast_2.1.0.tar.gz'
Content type 'application/x-gzip' length 331500 bytes (323 KB)
==================================================
downloaded 323 KB

* installing *source* package ‘Rfast’ ...
** package ‘Rfast’ successfully unpacked and MD5 sums checked
** using staged installation
** libs
g++ -std=gnu++17 -I"/usr/share/R/include" -DNDEBUG -I../inst/include -I'/home/liudefu/R/x86_64-pc-linux-gnu-library/4.1/Rcpp/include' -I'/home/liudefu/R/x86_64-pc-linux-gnu-library/4.1/RcppArmadillo/include' -I'/home/liudefu/R/x86_64-pc-linux-gnu-library/4.1/RcppParallel/include'   -fopenmp -fpic  -g -O2 -fdebug-prefix-map=/build/r-base-J7pprH/r-base-4.1.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g  -c Coeff.cpp -o Coeff.o
In file included from ../inst/include/Rfast/templates.h:10:0,
                 from ../inst/include/Rfast/matrix.hpp:14,
                 from ../inst/include/Rfast.h:5,
                 from mn.h:4,
                 from Coeff.cpp:4:
../inst/include/Rfast/parallel.h:20:10: fatal error: execution: No such file or directory
 #include <execution>
          ^~~~~~~~~~~
compilation terminated.
/usr/lib/R/etc/Makeconf:177: recipe for target 'Coeff.o' failed
make: *** [Coeff.o] Error 1
ERROR: compilation failed for package ‘Rfast’
* removing ‘/home/liudefu/R/x86_64-pc-linux-gnu-library/4.1/Rfast’
* restoring previous ‘/home/liudefu/R/x86_64-pc-linux-gnu-library/4.1/Rfast’
Warning in install.packages :
  installation of package ‘Rfast’ had non-zero exit status

The downloaded source packages are in
	‘/tmp/Rtmplb0HeY/downloaded_packages’

This prevents me from using pecotmr

[danielnachun]

Thanks for giving details on the failure. I'll make another pitch here for the value of using micromamba or pixi to manage R packages on Linux - all of the dependencies as well as pecotmr itself are precompiled and will work on pretty much any Linux system. It's possible to use micromamba/pixi-managed R packages with jupyter, RStudio and VSCode - I haven't posted instructions for this yet but let me know if this is of interest and I can try to prioritize getting that up sooner.

If you can't or don't want to use micromamba/pixi to manage your R packages, you'll need at least GCC 7 for full C++17 support. @mumdark I'm assuming you're on an HPC cluster, likely running CentOS 7? If so there's a good chance your cluster administrators have already provided newer GCC versions, and you can adjust $HOME/.R/Makevars (or create it if it doesn't already exist) and point CC and CXX to the newer GCC version. If your cluster doesn't provide a newer version, there is also the option to use micromamba or pixi to install a newer GCC version and point your Makevars to that as well.

As @pcarbo suggested above, we will eventually make Rfast an optional dependency, but based on prior experience the performance for LD computation was very slow with other correlation methods.

Please let me know if you have further questions.

[pcarbo]

Just to add to what @danielnachun said, my imperfect solution was to install a previous version of Rfast that did not require C++17 (I believe it was version 1.9.9).

[mumdark]

Thanks for giving details on the failure. I'll make another pitch here for the value of using micromamba or pixi to manage R packages on Linux - all of the dependencies as well as pecotmr itself are precompiled and will work on pretty much any Linux system. It's possible to use micromamba/pixi-managed R packages with jupyter, RStudio and VSCode - I haven't posted instructions for this yet but let me know if this is of interest and I can try to prioritize getting that up sooner.

If you can't or don't want to use micromamba/pixi to manage your R packages, you'll need at least GCC 7 for full C++17 support. @mumdark I'm assuming you're on an HPC cluster, likely running CentOS 7? If so there's a good chance your cluster administrators have already provided newer GCC versions, and you can adjust $HOME/.R/Makevars (or create it if it doesn't already exist) and point CC and CXX to the newer GCC version. If your cluster doesn't provide a newer version, there is also the option to use micromamba or pixi to install a newer GCC version and point your Makevars to that as well.

As @pcarbo suggested above, we will eventually make Rfast an optional dependency, but based on prior experience the performance for LD computation was very slow with other correlation methods.

Please let me know if you have further questions.

Thank you for your help.

There's an issue with the dependency package stephenslab/fsusieR, which restricts the version of Rfast. Should I modify its namespace directly? @pcarbo

Thanks!

[pcarbo]

Yes, that's right, I tihink did this, although on second thought this could potentially cause unknown downstream issues with fsusie, so perhaps my suggestion is not great. Sorry for that. A better solution will be to install using an C++17-compatible compiler.

[mumdark]

Thanks! This still helps me a lot.