Make research on where the R package should be published

[grzanka]

We can use CRAN (current one) but there may be several other options:

• direct installation from github
• other repos: bioconductor, r-forge etc

Write down in this issues pros and cons for each other (with references_)

[Sharon131]

Possible R repos: ref 1 ref 2

CRAN:

• submissions only through web interface
• more stricted rules concerning how R package should look like
• it is possible to write program that would send HTTP POST requests to web interface
• it is also possible to use test API for web applications, e.g. Selenium (Selenium could also be used in CI) ref
• could require more work than using Github

Github/Gitlab repository: ref

• package must have its own repo
• installation is also quite easy (install_github command)
• it is possible to push certain files to another repo in Github Actions ref
• it would probably be needed to create repo for R package in advance and put its name and username to some file in C source repo (in here libamtrack)

Libamtrack Github:

• archived package could be stored in libamtrack repository (probably not recommended)
• installation would be problematic

R-Forge:

• is based on SVN repo
• could not much information about submitting package ref

Bioconductor: ref

• package should address areas of high-throughput genomic analysis, e.g., sequencing, expression and other microarrays, flow cytometry, mass spectrometry (libamtrack falls in here?), image analysis, etc.
• package should not exist on CRAN (problem: it was already added to CRAN once)
• package should be also on Github
• submission is done by creating issue on Github Bioconductor Contributions repo
• installation from Bioconductor is more complex (needed package BiocManager)

[grzanka]

I also support github and CRAN options.

One thing needs to be investigated, mainly whether package files needs to be precompiled

[Sharon131]

As far as understand, package files do not need to be precompiled when submitting to CRAN or Github. I checked an example R package repo (ref) from this book, and it does not contain any precompiled files. I also checked CRAN submitting policy (here), and it explicitly says that Source packages may not contain any form of binary executable code.. The only exception is if one of the depencies is dll, then package should contain them. I am not sure, how it behaves in terms of using C code. I read this and in the beginning it explains how to use functions from static library, but then in section Importing C code and Exporting C code dynamic libraries are described. It looks like it is about exporting and importing C code callings (.Call() and .C()) from and to other packages, which we do not need, but I am not sure. EDIT: Based on this .C() call calls build C code. But I also found this package on Github which does not contain build C code - probably user needs to compile it himself in order to use it. So, I would say, that package submitted to CRAN should have precompiled C code, while package on Github does not need to.

[Sharon131]

I installed this and this packages via install_github command as specified in here and checked that functions being C wrappers are working right away. I guess that compiling C source is part of a process of installing package from Github with aforementioned command. I only checked on Windows, but I think it should work the same on other OS'. Conclusion: Packages stored on Github do not need to be precompiled, they just need C and R source codes and DESCRIPTION file (it is checked during installation). It would also be good to have NAMESPACE file and some sort of documentation. When it comes to CRAN, packages stored there should contain precompiled C source code.

[grzanka]

I checked installation via install_github on fresh Windows. It doesn't work out of the box as it requires user installation of Rtools, which in fact contain a compiler and are a pretty large package.

I would say that CRAN is better in that case, as no compiler needs to be installed and this is what users prefer.

Another question - do we need to precompile the package to be uploaded to CRAN ourselves or CRAN does it for us?

[Sharon131]

According to section 4.4 in here packages submitted to CRAN should be in bundled form (I guess it is the same as precompiled) and its maintainers make binary versions, that are published alongside the bundled one. I also checked CRAN Repository Policy and in section Binary packages it says: Binary packages are not accepted from maintainers (here package maintainers, not CRAN): CRAN will only host binary packages prepared by those responsible for the binary areas. Their packages are made automatically by batch jobs and can take a day or two to appear on the CRAN master site (maybe longer to reach CRAN mirrors). It also says, that binary packages are made for Windows and MacOS. Also, I checked, and in bundled package C code is given as in .h headers and .c source files. It is not in .dll form until binary package (I think I mistook precompiled package as binary in previous comments). Conclusion: packages submitted to CRAN should be in budled (precompiled) form and they must not be in binary form (compiled for given OS).

[grzanka]

Thanks for a detailed explanation. I was also not clear mentioning precompiled. When saying here about precompiled I meant "compiled for given OS" not "bundled for the compilation".

Anyway, I would prefer a solution when a user doesn't need to compile the package himself.

[Sharon131]

Anyway, I would prefer a solution when a user doesn't need to compile the package himself.

In that case CRAN is more suitable.